Thanks for the reply.

Since my last posts, I have been fiddling around with the setup and noticed that when I directly poll the modbus tcp server, the updated state is made available almost instantaneously.

My issue is really on the polling side of the home assistant visualization I am using. I have now started a project to do the polling in a separate server, that then pushes out any changes in the form of an event via MQTT, see https://github.com/mhemeryck/unipusher . It currently works as a proof of concept for a single toggle switch, I am now looking into how I can make it more scalable to all kinds of inputs / outputs. I'll get back here if this ever works out :)

EDIT: given it's not really unipi specific, I decided to rename it to modbridge, see https://github.com/mhemeryck/modbridge

Ok; took me quite some time, but I just did manage to read out the sensor values.

Leaving this here as future reference; the involved PIR sensor was the Jablotron JS-20 Largo. A small schematic was provided with the sensor out of the box, but the key find for me was that the sensor outputs also need to be wired up to the 12V power source; see adapted schematic and pictures.

Thanks a lot for the schematics, since they really made it possible for me to reverse-engineer the setup.

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!

@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!!

Small update: check out my blog for the solution I did create https://blog.mhemeryck.com/2021-11-16/modbusbackup

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!

@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?)

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.

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:

1. push button triggers MQTT event (on a neuron L303)
2. MQTT event is picked up by home assistant (on a dedicated x86 computer) and send out another MQTT event
3. 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:

1. wiring; I did use 2 wires from a CAT6 ethernet cable and put these into the RS485A / B connectors
2. 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)
3. 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
4. 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?

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.

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.

Another update on the mains voltage wiring: https://blog.mhemeryck.com/2021-07-06/home_automation_schematics

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

@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 :)