Hello @knebb, as @ntd wrote there is no need to use the Evok (which is, basically a bridge between Modbus server and several web-service interfaces). The simplest option for direct access from a C/C++ application should be the sysfs interface. Of course, a Modbus client connected to the internally running Modbus server can be used also.

OK, now it is a bit clearer. You probably did not insert TCP port while you have been asked for it during the installation process. Default values within the file are:

upstream evok {
        server localhost:8080;
}

server {
	listen 80 default_server;
	server_name  _;

	#ssl on;
	#ssl_certificate      /etc/nginx/democert.pem;
	#ssl_certificate_key  /etc/nginx/democert.key;

	#access_log  /var/log/evok.access.log;
	access_log  off;
	root /var/www/evok;

	location / {
	    index index.html;	    
	}
	
	location /favicon.ico {
		alias /var/www/evok/favicon.ico;
	}

	location /ws {
		proxy_pass http://evok;
		proxy_set_header Host $host:$server_port;
		proxy_http_version 1.1;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "upgrade";
		proxy_buffering off;
		proxy_cache off;
		proxy_read_timeout 180;
	}

	location /rest {
		proxy_pass http://evok;
		proxy_set_header Host      $host:$server_port;
	}
	
	location /json {
		proxy_pass http://evok;
		proxy_set_header Host      $host:$server_port;
	}
	location /bulk {
		proxy_pass http://evok;
		proxy_set_header Host	$host:$server_port;
	}
	location /rpc {
		proxy_pass http://evok;
		proxy_set_header Host	$host:$server_port;
	}
	
}

Hello @marioverhaeg,

sorry for the very late reply. Have you already solved the issue? If so, can you please share the solution?

Thank you so much!

Hello @emomiilol ,

can you please share a set of all SW you are using for this test with its configuration?

The main reason can be the sampling rate of the A/D converter. For full resolution, there are 2-4 samples per second only. See excerpt from the MCP3422A0 datasheet:

The issue was caused by a combination of 64bit Linux kernel and bundled pigpio subsystem (used for peripheral access). After pigpio updating, Evok works on a 64bit platform properly. This change will be part of the next release.

Hello @marioverhaeg,

I have replied you on your email - please provide us with more info. Then, I copy the right solution to this topic.

Hello @PythonRunner ,

it seems weird. There should be no traps - just one MCP23008 in the "typical" schematic.

Do you have a power supply for the EMO board strong enough?

Have you checked the functionality even with the Unipi software (e.g. Evok)?

Hello @Stoeffel ,

it seems that you access the serial (RS485) line from multiple applications which confuses Evok. Can you try to disable other processes potentially working with HW and leave running Evok only?

Hello @smontosa,

please try to download the current version 2.4.10. The issue should be fixed. Please note that watchdog settings (same as other parameters) are stored in RAM memory by default. To burn it into non-volatile memory (FLASH), use the appropriate coil 1003 or call the separate REST request on the same endpoint with parameter nv_save=1.

Hello @Stoeffel,

the issue should be fixed in the current release. Please upgrade to version 2.4.8.

Hello @DAWaller,

can you please describe your application in more detail? Websocket connection is provided by Evok software. Node-RED uses this type of connection to communicate with the I/Os.

Do you see the connection outages from Node-RED running on the same unit?

What displays the Node-RED debug console?

Hello @mglowinski,

sorry, but this feature is not supported in Unipi 1.1 series products. Please consider buying Neuron/Patron series PLCs which can do it.