It looks like EVOK is not running. Please try using:

sudo su
systemctl status evok
systemctl status unipitcp

The output should at least say what's gone wrong. I will try to replicate it locally as well, but it may take a while.

Apologies, it looks like you will have to use

apt-get install unipi-kernel-modules-dkms

instead of

apt-get install neuron-kernel

this will install the module from source, rather than using a precompiled binary.

The rest of the instructions should work fine. At any rate - we should release a new version tomorrow which should have the bug fixed.

Hi @thiagoralves!

I believe I have now identified the problem. Unfortunately the update above will likely not work (though it should not cause any harm either) - I will have to generate a new version of our kernel driver. This will take approximately 2 days; apologies for any difficulties caused.

The issue is that the secondary analog output is missing a correct error code for reading, which the primary analog outputs do have. This causes a null pointer dereference and a subsequent crash. That said - the crash occurs because the IIO kernel subsystem does not check for a null pointer value where it is permitted, which it should, so it is possible that a general kernel update (which the commands above will try to perform) may help. However a definitive fix will be creating a dummy method to pass to the subsystem, which is something we should do regardless.

Thank you for the debugging, and apologies for any problems caused. I should say that aside from reading the particular file there doesn't appear to be anything else wrong with the unit, and it should otherwise perform as expected.

Hi @thiagoralves!

The software version you have (both for firmware and kernel) is relatively old. I cannot guarantee it will fix the issue, but you should be able to update it easily by running:

sudo su
mount -o rw,remount /
echo "deb https://repo.unipi.technology/debian stretch main" >> /etc/apt/sources.list.d/unipi.list
wget https://repo.unipi.technology/debian/unipi_pub.gpg -O - | apt-key add
apt-get update
sync
reboot
----reboot occurs here----
sudo su
mount -o rw,remount /
apt-get install neuron-kernel
sync
reboot
----second reboot occurs here----
sudo su
mount -o rw,remount /
apt-get install unipi-modbus-tools
apt-get install unipi-firmware
sync
reboot

This should install the latest firmware, kernel and modbus server. Though unfortunately I really cannot say if that will fix the issue right at this very moment. I'll have a look into the code in the meanwhile, but please do see if the commands can fix the issue.

I will check the image on our download server to see if I can get it updated. If you do encounter any errors in the installation process then please do post here; the packages are tuned for a standard raspbian image, and may possibly not work properly with the older image from our server.

Hi @thiagoralves,

It looks like there is either an issue with the driver or the hardware. The driver shouldn't be doing this certainly, ideally under any circumstances - though realistically we cannot always prevent it. I'll try it locally with our own M503 - as you have used the latest image you should have both the latest firmware and driver, so there is definitely something fishy going on there! I'll have time to look at it on Monday at the earliest, but at least I can definitely say that this functionality has been tested in the past, but there have been some changes relatively recently which could have broken it.

One other thing you could do is try to run

sudo /opt/unipi-bin/fwspi -i 1

and paste the result here; it should show firmware details about the analog board. It might help us look at the test logs for the specific hardware unit and firmware version, to see if there's anything out of ordinary there. But I assume the issue will lie with a recent rewrite of the kernel driver.

Thank you again for reporting the issue, and I hope this isn't too much of a setback. And one other thing related to the SYSFS - you should set the scanning frequency higher, since all SYSFS inputs run on various multiples of it. The low initial setting is to prevent the communication bus from getting unnecessarily overcrowded when using another IDE such as Mervis or CODESYS, which sidestep it by using the /dev/neuronspi character device directly.

Edit: Another useful thing might be output from

sudo dmesg

at some point preceding the crash. This will show details about the kernel driver.

HI @luc!

Our I/O circuitry on Neuron (unlike the UniPi 1.1) is not directly connected to the Raspberry PI GPIOs, which is what PiGPIO is exclusively based upon - while you can install it, it will not be possible to read the Neuron digital inputs using the PiGPIO library. All references to PiGPIO in EVOK are related to UniPi 1.1.

That said - you can still access the inputs as any other GPIOs, just not with the PiGPIO library, which - as the name indicates - only works with the native RaspberryPI circuitry. Depending on the speed you need you may be able to read the wiegand protocol with the DIs directly, though unfortunately not with the script you linked.

I hope this helps

Hello @Gradient!

It looks like you are right, the bulk on/off commands for UniPi 1.1 relays are broken. This is specific to these commands, as the issue is that all the relays are multiplexed via a single I2C controller chip and require feedback from the previous operation before the next one can be planned - which cannot happen when using the bulk commands as they currently are.

I should be able to fix this shortly; the bulk API has been conceived long after UniPi 1.1 went into maintenance mode and was not thoroughly tested with it for that reason.

My coworker has also forwarded to me your other email queries regarding JSONRPC, but unfortunately I have to say I was not able to replicate those - the relays appear to behave exactly as specified in that case. There is a delay between the individual RPC commands, but as each command is effectively a single HTTP request they will be necessarily serialised. They do however serialise correctly, which I've tested by switching all the relays every 50ms (and I'd like to note that the relays are not designed to switch at anything approaching these frequencies; they have an average lifetime of 10 000 state changes under load, 100 000 without)

Hello @thiagoralves!

I agree that EVOK puts quite a heavy layer between the hardware and the application. You can significantly increase the speed by a) increasing scanning frequency in the configuration file and b) disabling or lowering debouncing (this is only relevant with >20Hz scanning rates).

Regardless - yes there is in fact a ModBus server! This is how both CODESYS and Mervis IDEs communicate with the device. The internal architecture looks like this:

• Web GUI/App
• ------ Network Stack ------
• EVOK
• TCP Modbus server written in C
• GPIO/IIO/LED/etc. drivers, with SYSFS support (Note that these are written by UniPi, and are not connected to the RPI GPIOs in any way! All internal communication is via SPI; also the ModBus server does not use these but rather communicates with the device directly)
• UniPi SPI 8MHz /12 MHz driver (custom Modbus-based, though not Modbus-compatible, protocol; described in https://git.unipi.technology/UniPi/unipi-kernel/src/master/docs); this is exposed via a character device in /dev/unipispi
• 48MHz STM CPUs on custom PCBs keeping state and performing the SPI commands, providing electrical separation, additional ESD protection and hardware redundancy

You can connect to the system at any desired level; large parts of our software including the driver and ModBus server are open source, which should provide you with all that you will need. For the ModBus server you'll also want the relevant ModBus maps, which you can find here. You may benefit from looking at the Mervis implementation as well - it is possible to use for evaluation purposes without a license, with only limited missing functionality.

You should be able to squeeze out sub-millisecond communication rates easily enough, though it does get dicier in the microsecond range, largely because the RPI HW will not be able to keep up.

I hope this helps

@thiagoralves

I had a look at OpenPLC and I apologise if some of my comments above came across as a bit patronising; we have a wide range of customers in terms of skills. Our preferred solution is to use a firewall for security if at all possible, and we would rather discourage users from making the device publicly available at all, which is why binding to a specific IP is not a configuration option (though I'd like to reiterate that binding to a specific interface is considerably more complicated). You can easily implement it within EVOK by changing the line 1718 in evok.py, from

httpServer.listen(port)

to,

httpServer.listen(port, address="127.0.0.1")

or some variant thereof.

That said, changing the port should indeed be working and would personally be my preferred solution. I am quite keen on finding out why the port is still reserved if you have changed the configuration and restarted EVOK.

@thiagoralves

You are very welcome to try and implement this yourself, but we currently have no plans to support this functionality. Most other similar IoT API frameworks, e.g. OpenHab, also opt to rely on IP filtering instead, and I believe it is far more straightforward and simple to setup. We would be happy to accept your code, and do have ours public if you wish to keep them to yourself. I understand this may seem like basic functionality, but to my knowledge it isn't simple or straightforward to implement in the version of Tornado which we use. What is easy to implement is only listening to a specific IP address, but binding to a specific interface, such that you can run two servers on the same port at once, one of which is 0.0.0.0, is considerably more tricky.

As for the second part of your question - you should be able to see which programs are bound to a port via the "netstat -paunt" command - I believe this may in your case be either NGINX or perhaps an older instance of Evok. Do get back to us with an output of the command if changing the port in the configuration file (both /etc/evok.conf and /etc/evok-nginx.conf) and rebooting does not help.