Small update: check out my blog for the solution I did create https://blog.mhemeryck.com/2021-11-16/modbusbackup
Posts made by Martijn Hemeryck
-
RE: Connecting 2 unipi controllers over RS485
-
RE: Connecting 2 unipi controllers over RS485
Small update: I can confirm a connection between the two unit if I run a modbus server on the slave device; setup:
- slave device: run https://github.com/riptideio/pymodbus/blob/731b080df0d277f0c6c32c949667a24a69a6bd7b/examples/common/synchronous_server.py
- master device:
mbpoll -t 0 -m rtu -P none -a 100 -b 19200 /dev/ttyNS0
(sidenote: I first tried the asyncio version, but still had some bug in it ... https://github.com/riptideio/pymodbus/blob/731b080df0d277f0c6c32c949667a24a69a6bd7b/examples/common/asyncio_server.py)
It's not doing anything useful atm, but I can see both master and slave pinging back to each other!
-
RE: Connecting 2 unipi controllers over RS485
@Martin-Kudláček said in Connecting 2 unipi controllers over RS485:
it is unclear for me what you have configured on the "other" side. On one side, you are using mbpoll, which is correct - it acts as a Modbus master. On the "other" side, there has to be some software running, which will act as a ModbusRTU slave device.
Ah indeed, I figured that there would already be some modbus client on the other end.
I will have a look at if it's possible then have such a client application using pymodbus as you mentioned.
It's just because of this article https://www.unipi.technology/news/the-four-ways-to-set-up-your-automation-project-257 (option 3). Perhaps this is a setup which is supported with mervis?
As for the resistors: I did notice a DIP switch on both my unipi controllers -- I assume these are related to enabling these resistors? And if so, I should only toggle them once (preferably on my "slave" device, since it should be the last in the series?)
-
RE: Connecting 2 unipi controllers over RS485
Thanks for your feedback.
You can choose either hardware- or software-addressing. If you want to use software you should set all DIP switches to 0. Otherwiese you use hardware-switching (which seems to be recommended for beginning).
I do not know if you have seen this document but I guess is will help
The document you point to is about addressing an extension module from a controller module. My use case is about 2 controllers talking directly to each other. It also has a single DIP switch, but I guess this is to enable the internal terminal resistor (which I probably should do).
Otherwise have you considered using network with MQTT between these two devices?
Yes, that is actually my current setup. Have a look at https://blog.mhemeryck.com/2021-06-15/home_automation_why and related posts :)
The reason why I would like to connect the 2 modules directly together is that I would not need a network connection and no other software in between. While that setup works OK for me, I think it would be nice to have a direct connection as a fallback.
-
Connecting 2 unipi controllers over RS485
I currently have a setup where all my input switches are on a single unipi controller and all the relay outputs are on another. The connection between the 2 of these is done with an automation in home assistant, using MQTT.
So, pushing a push button to switching on the light means:
- push button triggers MQTT event (on a neuron L303)
- MQTT event is picked up by home assistant (on a dedicated x86 computer) and send out another MQTT event
- MQTT event triggers a relay toggle (on a neuron L403).
While this has been working OK for me, I have been thinking about some redundancy and would like the overall basic system to still working without home assistant and without a network connection.
I was reading https://www.unipi.technology/news/the-four-ways-to-set-up-your-automation-project-257 the other day, and I did notice the possiblity to link some unipi controllers directly using RS485 / modbus RTU. My idea would be that a button press on the L303 would then just directly send a command over modbus RTU to the L403. Apart from that I would also still keep the MQTT interface, such that home assistant can still work with it.
Up to now however, I haven't been able to connect the 2 together.
What I did try:
- wiring; I did use 2 wires from a CAT6 ethernet cable and put these into the RS485A / B connectors
- DIP switches: I read somewhere these need to be on such that the line is properly terminated (tried actually in a bunch of on / off configurations)
- software: the evok interface shows me the serial 1.01 ports for both controllers is 19200 baud rate, 8 bits, no parity stop bit 1
- I did try reading data from the serial line using
mbpoll
, e.g.
sudo mbpoll -t 0 -m rtu -P none -a 15 -b 19200 -r 100 -c 20 /dev/extcomm/1/0 mbpoll 1.4-12 - FieldTalk(tm) Modbus(R) Master Simulator Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; type 'mbpoll -w' for details. Protocol configuration: Modbus RTU Slave configuration...: address = [15] start reference = 100, count = 20 Communication.........: /dev/extcomm/1/0, 19200-8N1 t/o 1.00 s, poll rate 1000 ms Data type.............: discrete output (coil) -- Polling slave 15... Ctrl-C to stop) Read discrete output (coil) failed: Connection timed out -- Polling slave 15... Ctrl-C to stop) Read discrete output (coil) failed: Connection timed out ^C--- /dev/extcomm/1/0 poll statistics --- 2 frames transmitted, 0 received, 2 errors, 100.0% frame loss
Any clue what I'm doing wrong?
-
RE: home assistant DIY setup blog
Thanks a lot for the feedback!
Hi @Martijn-Hemeryck,
I checked your other posts and have some notes on the Software part:I think it's really nice you took this effort, tbh :)
The Evok is planned (well, maybe "wished" is a better word:)) to be rewritten to Python 3 and to a multithreaded application. Along with that, major changes to the API will happen. We will abandon some of the less used APIs (RPC and SOAP probably) and definitely add native MQTT support since it is a driving force in the industry.
How far along is this idea? Would you also be taking PRs? I mainly develop in python3 for my job and have some experience with asyncio (see e.g. https://github.com/mhemeryck/covers), so I might be interested to have a look at that.
The missed state changes of the DI can be detected by checking the state of the DI counter. The counter is implemented in the HW and can count as fast as 10kHz signals.
I wasn't aware of this polling speed!
And a bit of explanation of the low level communication:
- The HW boards are connected over SPI
- The protocol on the SPI level is modified ModbusRTU
- The Unipi kernel module (part of the unipi-kernel-modules package) exposes this communication channe as /dev/unipispi device
- The Unipi ModbusTCP server (part of the unipi-modbus-tools) exposes this as a ModbusTCP server running on TCP/502
- The rest is correct. Evok polls the ModbusTCP server as fast as it can. And creates a "system image" of the HW state.
I obviously did get some of details wrong, so thanks for pointing this out!
Would you mind if I did include your comments in an edit on this blog post?
I really appreciate this kind of feedback; I never really did ask for your permission to publish on your product in the first place, so I am glad to see your reaction like this.
-
RE: home assistant DIY setup blog
Keeping it with my weekly tradition: https://blog.mhemeryck.com/2021-07-13/home_automation_cabinet
This one might be a bit more interesting in that it gives some more details on the actual wiring I did.
-
RE: home assistant DIY setup blog
Another update on the mains voltage wiring: https://blog.mhemeryck.com/2021-07-06/home_automation_schematics
-
RE: home assistant DIY setup blog
Update: to keep the habit of posting new posts: here's the post on wiring: https://blog.mhemeryck.com/2021-06-29/home_automation_wiring
-
RE: home assistant DIY setup blog
@Martin-Kudláček thanks for the feedback.
For the redundancy: I think there's multiple ways in which to add some safeties, some I have already implemented:
- 24VDC UPS: pretty much everything that I have on the 24VDC side is secured by a battery + UPS. In the event of power failure, my unipi units will not directly lose power. The UPS has a dry contact to indicate its loss of power, so I'm thinking of also adding a controlled shutdown in this event.
- additionally, all network hardware I have is also protected with batteries.
- home assistant container orchestrator: I run the home assistant instance using https://k3s.io/ which is a low-memory footprint version of kubernetes (the de-facto industry standard for running containerized workloads). The advantage is that it should auto-recover the home assistant instance in case of failure. I particularly like the feature that in case of updates, it will try to run the new version alongside the old one and only if the new one is confirmed up and running, it will kill of the old version. Another feature is that you can run it in a high-availability (HA) mode, i.e. over multiple nodes (e.g. raspberry pis) such that if one nodes fails, it automatically distributes the load to another node. For quick provisioning: check https://k3sup.dev/
- home assistant config: the entire config is kubernetes yaml manifest files, so in case of failure, I could easily redeploy the entire thing.
- MQTT broker in HA mode: there's apparently another MQTT broker out there that you can in HA mode, see https://www.emqx.io/blog/emqx-mqtt-broker-k8s-cluster
- home assistant backups: currently, all logical links between MQTT topics is done using the home assistant automations, but at some point I did think to add another service in the network that could do something similar. My shades control actually works in such a way, that it handles some more involved logic for translating MQTT events between the home assistant instance and the unipi unit: https://github.com/mhemeryck/covers (probably deserves its own blog post to really explain :))
- on the network level: most of the setup relies on a wired network setup, but I also did consider to maybe have a wireless failover (not implemented yet though).
Maybe this list is also a great topic for a future post :)
-
RE: home assistant DIY setup blog
Update: here's the second post in the series: https://blog.mhemeryck.com/2021-06-22/home_automation_architecture
This post outlines the architecture and the framework I did use while modelling the overall setup.
-
home assistant DIY setup blog
While building our new house, I did spend a lot of time on designing and later building a home automation system, with home assistant + MQTT at its core.
Today, I did post the first of a series of blog posts on this topic: https://blog.mhemeryck.com/2021-06-15/home_automation_why
The first post is mostly about explaining the rationale behind it as well as the series of posts I have actually planned over the course of the following weeks.
At this stage, it does not mention any unipi product yet, but as the series unfolds, it should be clear that my unipi neuron units are really essential in the overall setup :)
Hope you might enjoy it!
-
RE: Stuck relays controlling blinds
@Petr-Helebrant Thanks for your reply.
in the end, I did indeed end up putting in a separate series of relays to control the blinds. I did use relays from Eltako though, which were a lot more expensive than the solution you did provide. Thanks anyways for the tip, I can imagine it to come in handy for a future project.
-
RE: Stuck relays controlling blinds
Replying to my own question here:
Later in the day, after some back of forth switching of the relays I was able to get 3 of the 4 relays functioning again (the other one seems lost).
My guess is that it's probably not ideal to use the simple built-in relays to drive the motors directly, so my current thinking is to have a look at a set of external relays to drive the motors.
-
Stuck relays controlling blinds
Re: Stuck Relays
I have a similar issue on my unipi neuron L203 when trying to control blinds.
The blinds operate with 2 relays: one for up and one for down.
The specs mention a rated current of 0.49 A, so I figured it would be fine to drive them with the built-in relays. Given I got the issue on 2 blinds shortly after each other, I'm not so sure anymore whether I can actually use them to directly drive the blinds.
Even after powering down, I can measure (with a multimeter) that the 4 relays are still given contact -- so I'm fearing the worst, that the contacts really got stuck.
Is there anything I can do in this situation?
Thanks in advance
-
Axon S605 upgrades
Hi,
I wanted to run some regular updates today, but I kept on getting issues with some dependencies such that I ended up uninstalling some, in order to check if I could just reinstall them. Unfortunately, some of them were quite critical such that I ended up flashing the entire device ...
Anyways, I do have a working axon S605 again (for some reason, it even still had my local files on it). but it now seems your debian repo isn't reachable: https://repo.unipi.technology/debian . Any idea what might be the issue and how to resolve it?
-
RE: Neuron L303 and M303 DI not working -- LED not showing
@martin-kudláček said in Neuron L303 and M303 DI not working -- LED not showing:
mbpoll 127.0.0.1 -a 0 -0 -1 -r 1136
mhemeryck@L303-sn17:~ $ mbpoll 127.0.0.1 -a 0 -0 -1 -r 1130 mbpoll 1.4-12 - FieldTalk(tm) Modbus(R) Master Simulator Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; type 'mbpoll -w' for details. Protocol configuration: Modbus TCP Slave configuration...: address = [0] start reference = 1130, count = 1 Communication.........: 127.0.0.1, port 502, t/o 1.00 s, poll rate 1000 ms Data type.............: 16-bit register, output (holding) register table -- Polling slave 0... [1130]: 50 mhemeryck@L303-sn17:~ $ mbpoll 127.0.0.1 -a 0 -0 -1 -r 1137 mbpoll 1.4-12 - FieldTalk(tm) Modbus(R) Master Simulator Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; type 'mbpoll -w' for details. Protocol configuration: Modbus TCP Slave configuration...: address = [0] start reference = 1137, count = 1 Communication.........: 127.0.0.1, port 502, t/o 1.00 s, poll rate 1000 ms Data type.............: 16-bit register, output (holding) register table -- Polling slave 0... [1137]: 65535 (-1)
Right, so it indeed looks like a very high debounce time!
Strange, since I thought I had already checked that with the web view / can't recall changing it myself.
Anyways, I ran the firmware updates again, and now it's fixed! Thanks a lot!!
-
RE: Neuron L303 and M303 DI not working -- LED not showing
@martin-kudláček I did try they approach you suggested:
- I did not have my own custom software running right now (or before), so this shouldn't have been the issue
- I did check first for e.g. di_2_13: reaction was pretty much instantaneous
- Afterwards, checked for di_2_27: same reaction time as when I check with the LED indicator lights
Any other things I can check? Thx!
-
RE: Neuron L303 and M303 DI not working -- LED not showing
Update: I did check the issue with the faulty DIs again and I did notice that they actually still do respond -- but only after a 10s delay. This delay seems consistent for all the DIs. Additionally, it all concerns the upper 4 DIs (27...30) in all cases.
My guess is thus that it's probably not due to a hardware issue but rather a firmware issue.
Is this a known issue? Could this be related to the latest firmware upgrade?
-
RE: Neuron L303 and M303 DI not working -- LED not showing
@martin-kudláček said in Neuron L303 and M303 DI not working -- LED not showing:
sudo /opt/unipi/tools/fwspi --auto -PR -v
Thanks for the quick reply. I did try the upgrades as you suggested.
There was no dist-upgrade to perform -- could run the firmware upgrade for L303:
mhemeryck@L303-sn17:~ $ sudo apt install unipi-kernel-modules [sudo] password for mhemeryck: Reading package lists... Done Building dependency tree Reading state information... Done Package unipi-kernel-modules is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: unipi-kernel-modules-dkms E: Package 'unipi-kernel-modules' has no installation candidate mhemeryck@L303-sn17:~ $ sudo apt install unipi-kernel-module Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package unipi-kernel-module mhemeryck@L303-sn17:~ $ apt-get dist-upgrade E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied) E: Unable to lock the administration directory (/var/lib/dpkg/), are you root? mhemeryck@L303-sn17:~ $ sudo apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. mhemeryck@L303-sn17:~ $ sudo /opt/unipi/tools/fwspi --auto -PR -v Board on /dev/unipispi firmware=5.3 hardware=0.1 (B-1000) (spi 8MHz) NEW firmware=5.40 found N2000 = 22 8800 OK e000 OK REBOOTING... Board on /dev/unipispi firmware=5.3 hardware=10.1 (E-16Di_U-14Di) (spi 8MHz) NEW firmware=5.40 found N2000 = 37 8000 OK e000 OK REBOOTING... Board on /dev/unipispi firmware=5.3 hardware=10.1 (E-16Di_U-14Di) (spi 8MHz) NEW firmware=5.40 found N2000 = 37 8000 OK e000 OK REBOOTING... Firmware autoupdate finished
After testing the involved DI ports, I still could not see any LEDs lighting up ... Would it make sense to break the seal and have a look at the DI board itself? Or what would be the best next step to check?