administrators

Hi @Boy-Lenssen!

Apologies for the slightly delayed reply, I was on a brief vacation for the past few days. The timeout is set to 30 seconds of the receiving device not responding, which is default for the Tornado server. It is possible to set this higher in the code, but it can cause issues with connections not being closed at times they should be.

Unfortunately it is also the case that WebSocket does not run immediately at startup, but requires approximately 15s from device boot to become fully responsive. This is mostly because of the Python backend of the server. However you shouldn't be able to connect to it until it is fully established.

I hope this helps

Hi @dalibor ,
that's odd, it should definitely work. Can you share the project with me on support@unipi.technology?

Thanks,
Martin

Hello @stevenbrs,
The ModbusTCP server on localhost:502 is only for communication with the inner hardware of the PLC, not with the extensions.
The extensions are to be connected by RS485. In the OS, you have this HW serial port accessible as /dev/extcomm/0/xxx, depending on the order of the serial port on the PLC (RS485 1.1 is /dev/extcomm/0/0, RS485 2.1 is /dev/extcomm/0/1,...).

With situation like this, you need to convince the Home Assistant to communicate by ModbusRTU protocol via mentioned serial port.

The communication of the ModbusTCP server with the inner HW of the PLC is reasonably fast. The speed problem you are experiencing almost always lies in the software which communicates with the ModbusTCP server. We have seen it across all diferent kinds of applications even with our very own Mervis. Few weeks ago, we have discussed this on another thread: https://forum.unipi.technology/topic/694/unipi-neuron-home-assistant-setup/2

Unfortunately we don't have any direct experience with the Home Assistant, so I am not able to give you any direct advice. Maybe @Martijn-Hemeryck could chip in:)?

Best regards,
Martin

Hi @stevenbrs,

The DOs are NPN type (open collector), check the documentation for proper wiring. Everything is OK with your HW and SW, do not worry.

@martin-kudláček Already noted on the prepared knowledge base.

@mdturnerphys Sure! We expect to release the new Mervis IDE and required tutorials on our new knowledge base this Friday.

@alydersen That will be a tough decision where to put it, but I'll think of something.

Thanks for the feedback,
Martin

Hello @alydersen
yes, this a security feature, because ModbusTCP doesn't have any autentization.

The unipitcp service is maintained by systemd and the startup parameters are defined in /lib/systemd/system/unipitcp.service. You can modify the ExecStart attribut in this file and add -l 0.0.0.0 to start the service listening on all IP address, not just default loopback.

The result should look like this:

[Unit]
Description=Unipi Neuron/Axon Modbus/Tcp Server
Before=mervisrt.service
Before=evok.service

[Service]
Type=simple
Environment="FIRMWARE_UPDATE=1"
EnvironmentFile=-/etc/default/unipi-modbus-tools
ExecStartPre=/bin/sh -c 'if [ "${FIRMWARE_UPDATE}" = "1" ]; then /opt/unipi-bin/fwspi --auto; fi'
ExecStart=/opt/unipi-bin/unipi_tcp_server -p 502 -l 0.0.0.0
TimeoutStopSec=3
SyslogLevel=debug
SyslogIdentifier=unipi
WorkingDirectory=/opt/unipi-bin

Restart=always

[Install]
WantedBy=unipispi.target

Then reload the systemd: systemctl daemon-reload
And reload the unipitcp service: systemctl restart unipitcp

Regards,
Martin

Hooray @alydersen! Thanks for the feedback, we will update the documentation.

Martin

Hello @alydersen
I was unable to reproduce the problem. I followed this scenario and the evok is working out of the box:

1. Download the image and flash it to the SD card using WIn32DIskImager: https://downloads.raspberrypi.org/raspbian_lite_latest
2. Start the PLC and SSH into it
3. sudo bash
4. apt update
5. apt upgrade
6. reboot
7. At this point I have a up-to-date Raspbian. I SSHed again
8. sudo bash
9. apt install nginx
10. rm -f /etc/nginx/sites-enabled/default
11. apt install unipi-modbus-tools
12. apt install evok
13. reboot

And the evok after reboot works:

I can see from your output that you have a different version of kernel (4.14.50-v7+ vs. 4.14.69-v7+ in up-to-date Raspbian). What image do you use?

Martin