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.

Hello @witenite,

I suppose you are running our official Node-RED Image. In this case, there is the underlying software Evok that makes the PLC I/Os (including 1-Wire) available to the Node-RED IDE via Unipi nodes. To avoid 1-Wire bus access conflicts, the appropriate kernel module (named ds2482), managing also sysfs access through /sys/bus/w1/devices, is disabled by default.

Basically, you have two options (that cannot be combined mutually):

1. Use Evok and Unipi node(s) to read data from sensors in Node-RED - then follow this tutorial. This is the default state.
2. Disable 1-Wire support in Evok (comment the OWBUS section in /etc/evok.conf), enable the module loading( add/uncomment "dtoverlay=ds2482" in /boot/config.txt), and use some other nodes (e.g. the one meant in your post) to access the 1-Wire bus.

Hello,

yes - several versions back, there was a change in Evok package (underlying layer for communication with I/Os) regarding 1-Wire access method. The kernel driver for the 1-Wire master is removed as Evok uses another method (OWFS) instead.

Basically, you have two options possible:

1. Use Evok - follow THIS tutorial
2. Disable 1W bus in Evok (comment it out in the /etc/evok.conf) and enable DS2482 kernel module loading by enabling the ds2482 device-tree overlay in /boot/config.txt. In this case, you, of course, cannot use access to a sensor through the Unipi node anymore.

Hello @Balardo,

you are right - there was a bug in schema validation for /json/all endpoint. It should be fixed in the next release.

According to the direct Modbus unit register access - you can use e.g.
http://<your IP>/json/unit_register/UART_15_2_42

to get the ambient_light register:

{"status": "success", "data": {"name": "ambient_light", "value": 122.51519775390625, "glob_dev_id": 2, "dev": "unit_register", "circuit": "UART_15_2_42", "unit": "lux"}}

Register values has been also added to the web control panel:

You can test it by install the test version:

sudo su
apt update && apt install evok=2.3.3.test.20200923165635*

Hello @Balardo,

can you please share reply to the /rest/all GET request?
e.g. type http://<IP OF YOUR UNIT>/rest/all to your browser.

Hello @Stoeffel,

please try to uncomment following lines in the evok.conf within the xG18 section:

• allow_register_access
• scan_frequency
• scan_enabled

In case of no success, you can try to "hardcode" the serial line parameters (baud rate, parity, stop_bits) in the config file (by uncommenting appropriate lines).

Hello @sacha,

all Axon PLCs should be shipped with Debian 10 Buster inside. Of course, you can simply upgrade any older unit to the latest OS (all current OS Images are based on the Buster).

Images can be downloaded from our KB.

A tutorial of how to flash the image (same for all Axon OS Images).

Hello @daminou53 ,

what OS image are you using? Have you done any changes in network configuration (e.g. /etc/network/interfaces files)?
On the following lines, the connection is successfully initialized (probably with very poor signal quality) but immediately, the LTE service is restarted.

2019-02-14 11:31:58,599 - DEBUG - WAN IP 10.34.177.115, Private IP 10.21.8.1; NON-CONFLICT 
2019-02-14 11:31:58,600 - INFO - WAN IP ADDRESS: 10.34.177.115 INTERFACE IP ADDRESS: 10.21.8.1
2019-02-14 11:31:58,602 - DEBUG - RSSI: 19 sigqual: 6 net-type: 7
2019-02-14 11:32:00,023 - INFO - unipi-lte version 0.18 from 2019-02-14 11:11:00.068002 - Logging started..

Are you able to provide remote access to the unit?

In the meantime, you can try to install the new beta version:

sudo apt install unipi-lte=0.19*

Hello @pascal37,

thank you for the feedback. So, let us sum it up:

1. On ports other than 1.1, you've never seen the issue yet (tested over 50 days without reboot).
2. On port 1.1, the issue appears always in a few (approx. 10) days.
3. There is no correlation with any item in the system log (dmesg) recorded in the moment of failure.
4. Flash to the latest version 5.50 has not solved it.
5. An older PLC M505 does not have this problem (is the FW and image versions in it also the latest?)

If so, you are right - it seems to the issue is hardware-based and the unit has to be replaced.

Hello @pascal37,

thank you for the information sent. Unfortunately, based on it, we are not able to determine the exact source of the issue.
Can you please check the following:

1. Again, make sure you have the latest firmware in the I/O board flashed. Type:

/opt/unipi/tools/fwspi -i 0

2. Can you confirm that the i2c-0 error in the dmesg log appears always in the moment of communication goes wrong? It seems there is a correlation (863475 seconds is almost exactly 10 days).

3. Are you sure that no other running processes access the interface (/dev/ttyNS0)? Please check also your time-scheduled tasks (e.g. executed from cron).

4. Are you sure that no noise or interference from the environment or power supply can infiltrate the unit?

As the last resort, we are able to simulate your application with the same HW, but it will be pretty time-consuming. In the meantime, please use another RS485 interface.

Hello @ktanghe,

unfortunately, on the UniPi 1.1 series (including Lite version) this feature is not supported now. We will consider adding the feature in the next version of Evok. You should prefer a user-naming (aliasing, labelling...) of selected I/Os in the upper-layer software instead of the API tool.