Recommended way to access inputs/ooutputs
what is the recommended and most stable way to read inputs and control outputs? I have read several threads here and some state that websockets is recommended.
How does the websockets access the data?
We are planning to hook the UniPi Neuron via evok to our software PLC and thus i am asking for the best approach to do so. We have a MODBUS TCP client but i suppose the API provides better ways towards the in/outputs?
evok for Neurons is using the TCP Modbus and provides web interface and other ways of accessing the IOs and it also provides the devices on 1Wire network (which the Modbus does not do yet).
So it is up to you, some people use the Modbus because they already have it implemented in their solutions and some use websockets because its itsometimes easier to implement.
Btw. the more software the bigger chance that something goes wrong.
Thanks for the swift answer.
What is excluded from the Modbus TCP server, is it only the 1-wire devices or other assets too? I am asking to evaluate what else we would have to integrate.
Where can i get documentation about registers and data types? Is the set of registers fixed per model or can this change?
Yep, only the 1Wire is missing in the modbus. The modbus map is generated automatically but you will figure that out from the documentation at http://downloads.unipi.technology
I was wondering the same thing. Would Modbus be faster than Websockets or not? Also, looking through some code it seems Modbus is only supported for the Neuron. Is there a reason there's no support for the UniPi 1.1?
@cvdd Technically yes, because there is one more layer (Evok) that is between your application and the HW. The difference is that Modbus has to be polled and websocktets automatically broadcasts all changes to the connected clients. So it is up to you how often you want to pull for the changes (either from your app or from Evok).
Modbus is supported in Evok but only as a Client for the Modbus server that provides access to the IOs.
@tomas_hora Thank you for the helpful illustration. So Modbus would be the faster choice I see. Looking through the code, Evok uses https://github.com/UniPiTechnology/neuron_tcp_modbus_overlay when installed on Neuron to host a Modbus server. Does this mean an application can't directly connect to the underlying (middle layer in the graphic) Modbus server and always has to go through Evok which itself is a Modbus client but also hosts a server to channel through requests? And why is this only on Neuron and not on default UniPi with Raspberry Pi?
Essentially, what I'm really asking is what would be the fastest way for an application to interface with the standard UniPi (not Neuron)? Am I correct that Modbus is only an option for Neuron and not standard UniPi?
@cvdd Of course it can, you can install only the tcp_modbus_server and use it as interface to the IOs. Evok only provides adtitional HTTP services (REST, websocket) including 1Wire.
The first generation UniPi uses directly GPIOs of the RPi so we build evok that it directly uses the GPIOs. But the Neuro uses the SPI as shown in the illustration so we wrote a C application to handle that.
Than to your last question: The fastest would be to use the GPIOs and I2C directly. But how fast you need it to be? Evok is not enough fast(eg. websocket).?
@tomas_hora Thank you for your quick replies. I have a first gen UniPi and I would like to use Modbus to read/write the first relay for example. What are the steps I should take to make this happen? Just installing https://github.com/UniPiTechnology/neuron_tcp_modbus_overlay as I think you're saying probably won't work as this is specific for the Neuron. I need a Modbus server on the Raspberry Pi that can read/write the relays of the UniPi. How could this be achieved?
@cvdd https://github.com/UniPiTechnology/neuron_tcp_modbus_overlay is only for Neurons and will not work for the UniPi 1. For UniPi 1 there is only Evok as API from us. But if you need Modbus and do not want to use the HTTP REST api, websocket or JSON RPC, then take a look at someone implementing Modbus for UniPi 1