Best posts made by Martijn Hemeryck

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