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 @Maxiba,

the issue described occurs because the curl command sends two separate requests in fact (one for each input).

Opposite, the Python script does not have intelligence and sends exactly what you pass to it while Evok does not support this request syntax.

In your case, you can consider using JSON Bulk request to read/write more I/Os at once.

https://evok-14.api-docs.io/1.11/bulk/bulk-json-request

Hello @Jan-Toth,

you have not specified IDE/Language used. For example, in Mervis IDE you can use the following approach:
Automatic restart of the 1-Wire bus

Can you share more info about the application?

Hello @oflock,

thank you for using our products!

As the internal single-board computer has an onboard WiFi adapter with no external antenna outside the unit and the unit has a metal enclosure, the WiFi performance is probably affected by this. The other factor is some of the LTE bands used can interfere with the WiFi frequencies.

The WiFi adapter in the Axon PLC series is designed mainly for occasional service access and/or initial setup.

Hello @Lasse ,

this value is Unipi 1.1 specific and comes from pigpio subsystem tick value. From documentation:

tick: the number of microseconds since system boot. It wraps around after 1h12m

Hello @matthijs ,

you do not need to add any additional wire to connect data wires together on 1W-TH sensors. Terminals 1W> and 1W< are already interconnected internally. The SEDtronic sensor on the picture does not have these terminals -> in this case, you have to tie the wires manually ON THE SENSOR. According to the photo, you have to connect dark-green and light-brown wires together ON THE PCB.

Please let me know if the problem persists.

Hello @matthijs,

the order of two data wires on the 1W-TH sensor terminal can be random as both data lines are interconnected together here. All sensors connected to the hub have "daisy-chain" topology (not a star topology!) - if data lines are not coupled in sensor, data cannot pass-through to the rest of the network - this is why you see only the first of 1W-TH sensors.

Hello @matthijs,

there seems to be something wrong with the HW. I just tried to connect two 1W-TH sensors and one DS18B20 via the hub and there is everything OK in the Evok control panel:

Do you have tied data lines (RJ45 pins 6 and 7) together on the 1W-TH sensors?

Please read the related section on our KB.

You can also upgrade the Evok package to get the 1W devices listed under the right category:

apt update && apt install evok=2.3.5.test.20201112163426

Hello @matthijs,

you are right - the 1W-TH sensors are listed in the incorrect category in the WEB Gui. This bug will be fixed in the next release. Other channels (REST API, Websocket, ...) should be OK.

However, the 1W-TH sensor's detection is not affected by this. Can you try the following:

1. Go to http://<your unit IP address>/rest/all and look for the 1wdevice objects - are all sensors connected listed here?

2. Can you describe your application (exact components used and wiring diagram)?

Hello @Achilleas-Kotsis,

I have tried to upgrade the system from a few older images (also with DKMS drivers) and this kind of behaviour did not occur. The issue seems to be coupled with the filesystem write operation and the following sync (should be invoked by umount command in the script).

Moreover, the .inc file should be updated formerly within the upgrade process (as the step of unipi-common package postinst script).

Can you retry the whole process with a new uSD card? This kind of problems sometimes occurs on corrupted cards as the write operation is not fully synced in fact.

Hello @Achilleas-Kotsis,

you are right - the neuronee nor unipiee overlays should not be enabled. Can you please provide info about your image that you are upgrading? We will try to emulate the issue.