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.

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 :/

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

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

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)

@knebb, I have been successful with my Axon device couple months ago.

Here is my /etc/apt/sources.list.d/unipi.list:

deb https://repo.unipi.technology/debian bullseye main

These are the steps I followed:

sudo apt update
sudo apt upgrade
sudo apt full-upgrade

I didn't remove any packages after full-upgrade and simply rebooted with a backup in place. After restart, I removed all obsolete packages but those which had unipi or axon in name (see later).

Currently, I'm still using the kernel from Buster because the kernel packages in Bullseye appear to be broken. If I understand correctly, we should be able to use unipi-kernel-modules-dkms with the normal Debian kernel. Unfortunately, it currently has broken dependencies, namely the unavailable unipi-kernel-headers and unipi-os-configurator-data.

Here is the list of obsolete Buster packages I have left on hold:

• unipi-kernel-modules
• unipi-common
• axon-kernel-headers
• axon-kernel-image

Since I don't currently need a new kernel, I'm not in a rush to resolve this. However, it would be great to receive an official update.