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.

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

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

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.

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

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?

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

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

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?

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

I did buy a Neuron L303 and M303 somewhere last year, to get acquainted with the hardware and to write software to read the digital inputs (e.g. https://github.com/mhemeryck/unipitt).

Now that I am nearing the end of the electrical installation of my house, I did start wiring up all of my push buttons, only to find out that a large number of them simply do not work. I first figured it could be related due to the software (I did read there was an issue with the sysfs SDK on which my implementation was based), but the LEDs on the unipi itself does not even light up for these DI.

I am hoping it could be a software issue -- but since the LEDs aren't even showing I actually fear for a hardware issue. Can you help me to further debug this?

Hi all,

Just wanted to share with you that I did integrate you driver for the axon s605 into the upstream python-dali library; see https://github.com/sde1000/python-dali/pull/59

It's not part of any tagged release yet, but it should be part of the upcoming one.