DirectSwitch coils are unavailable after power outage

[kepi]

I have Axon L205 which worked flawlessly for 5 years. There was power outage tonight and when the power was restored, light switches didn't work.

Light switches are implemented via DirectSwitch toggle.

When I wanted to check status of DirectSwitch related Modbus coils, I found out that those are displayed as unavailable (in HA).

When trying to read coil status (i.e. coil 1010 via slave 3) from Python, I'm, getting:

Error reading coil Exception Response(129, 1, SlaveFailure)

What is weird is that most of coils are working, but not all of them.

• All basic coils are working on all 3 units
• Coils 1007 to 1015 returns Exception Response(129, 1, SlaveFailure) on all 3 units.

As we (obviously) really need light switches to work, I spend a lot of time today trying to find solution on forums, digging through other coils etc.

workaround

What I finally found after couple hours is that registers, which I don't normally use, works.

So for now, we have working light switches, but I would really like to find out what is the problem and if it can be fixed. I'm also worried, that next time it might be other coils and we will be screwed.

Btw. I'm not sure if this works for all groups, I needed it only on slave 3.

packages

unipi@holly:~$ dpkg -l | egrep "unipi|axon"
hi  axon-kernel-headers              1.20220117~buster-axon             arm64        Linux kernel headers for UniPi Axon controller
hi  axon-kernel-image                1.20220117~buster-axon             arm64        Linux kernel for UniPi Axon controller
hi  unipi-common                     2.14~buster                        arm64        Common utilities for Unipi/Neuron/Axon
ii  unipi-firmware                   5.66                               all          Firmware files for UniPi Neuron/Axon boards
ii  unipi-firmware-tools             2.20~bullseye                      arm64        Firmware utilities for Unipi Neuron/Patron/Axon/Iris controllers.
hi  unipi-kernel-modules             1.124.1.20220117~buster-axon       arm64        UniPi kernel modules
ii  unipi-modbus-tools               2.20~bullseye                      arm64        Modbus server for Unipi Neuron/Axon controllers.

fwspi

0:

• Boardset: 0 B-1000 (v1.0)
• Baseboard: 0 B-1000 (v2.0)
• Firmware: v5.58 (for 0-1)

1:

• Boardset: 8 E-16Di_U-14Ro (v1.0)
• Baseboard: 3 E-16Di (v2.0)
• Firmware: v5.58 (for 8-1)

2:

• Boardset: 8 E-16Di_U-14Ro (v1.0)
• Baseboard: 3 E-16Di (v1.0)
• Firmware: v5.58 (for 8-1)

[kepi]

And today it happened and all coils are unavailable. I can reach modbus server for extension (mbusd) without problem but main unit is out. Not sure if registers work, I'll try that in the morning.

One thing I found out is at least some debug info:

unipi@holly:/opt/unipi/tools$ sudo ./unipi_tcp_server --verbose --port 504 --listen 0.0.0.0
ADD CHANNEL: /dev/unipichannel1
Board on /dev/unipispi firmware=5.58  hardware=0.1 (B-1000) (spi 12MHz)
ADD CHANNEL: OK
ADD CHANNEL: /dev/unipichannel2
Board on /dev/unipispi firmware=5.58  hardware=8.1 (E-16Di_U-14Ro) (spi 12MHz)
ADD CHANNEL: OK
ADD CHANNEL: /dev/unipichannel3
Board on /dev/unipispi firmware=5.58  hardware=8.1 (E-16Di_U-14Ro) (spi 12MHz)
ADD CHANNEL: OK
ADD CHANNEL: /dev/unipichannel4
ADD CHANNEL: /dev/unipichannel5
UniPi TCP Modbus Server: Listening Connection Established RET:6
poll timeout = -1[ms]
Starting primary loop
Unexpected reply in READ_BITUnexpected reply in READ_BITUnexpected reply in READ_BITUnexpected reply in READ_BITUnexpected reply in READ_BITUnexpected reply in READ_BITUnexpected reply in READ_BIT

that unexpeted reply... is repeating forever

[AVsetula]

Hi @kepi

you can try the latest Opensource OS or Node-RED OS image for the Axon series.

Then install (or update) the unipi-firmware6 package and try to update the firmware.

If that doesn't help, you can send the controller to the Unipi service center for diagnostics.

Best regards,
Antonin, Unipi

[kepi]

@AVsetula thanks for reply!

So yesterday's whole Modbus stopped working wasn't true, problem is still same as originally reported. The issue had been in HA configuration, or better in the fact, that I addressed all coils via unit 0, which seems to no longer be supported in ModbusTcpClient Python library. I hit same problem when trying to debug the orginal issue so fortunatelly it cross my mind this might be the case (there is no mention of this in docs so I'm not sure why). Extension had been working simply because there had been slave attribute since begining. HA probably updated the library in latest update, hence Modbus dissapearance.

Anyway back to original issue - I tried to update firmware to lastest 5.x as I forgot that I have to manually update firmware after package update. Unfortunatelly it didn't help.

I'll try upgrading firmware to version 6 when the house warms a little :)

[kepi]

Just finally found some time to do the upgrade to unipi-firmware6 and unfortunatelly no change. Coils 1007 to 1015 still returns exception.

Sending for diagnostics would be great, but I suppose it would take couple days and nothing works here without Unipi. Time to plan some redundancy :/

[cleve]

Hello @kepi,
what does the fwspi output now? Could you try reflashing the firmware with -PRv parameters and then sending the output? Unfortunately sending for diagnostics does not seem viable to me, this is a discontinued and unsupported product, we might not have the spare parts available.

Also did you try it using our latest OpensourceOS image based on Debian 10 for Axon?

[kepi]

Unfortunately sending for diagnostics does not seem viable to me, this is a discontinued and unsupported product, we might not have the spare parts available.

@cleve I really hope it is viable, as, based on information from Antonin, I just got new Neuron last week so I can send you Axon for diagnostic. Can you please let me know some binding decision?

To clarify - after Axon discontinuation (which came totally unexpected), I decided that I'll buy something different than Unipi as I simply need something with longer support. I don't want unsupported OS and HW taking care of my house. But when Antonin mentioned I can send device to diagnostic and you are willing to help, it swayed me back and I chose Neuron as my new device, as there is Rapsberry inside and I'm hoping I can count at least on "life time" OS updates.

I think I understand your decision about Axon, but I'm now afraid to chose your other products, especially Patron, as I don't know when it would be discontinued too.

As for other recommendations, I'll try it and let you know. I just need to know if I can use spare Neuron if something breaks or if I'll be returning it.

[cleve]

Hello @kepi,

You are free to send the unit for a post-warranty repair, please see the Service conditions and form, note that here is a fixed diagnostics fee.

I fully understand, the situation with Axon is unfortunate. The compute board used in the Axon series were suddenly unavailable in the Covid shortages and the manufacturer decided to discontinue them, combined with bad downstream kernel support, the Axon series had to be ended.

With the Patron, this situation is vastly different, it uses our own compute board and we have full control over it, soc has long availability and good software support, so there are no worries about its lifetime.

Please note that a used product can not be returned.