With deCONZ v2.13.01 pin code cannot be set anymore, nor can arming be changed

I had the pincode sequences working fine with 2.13.00, but after updating the pin code can not be set anymore, nor the arm mode can be changed, even with the correct code. Has the methods changed or is this a bug introduced with 1.13.01?

Postman response:

It differences when used by my plugin:

21:34:47.1993595 – (BridgeApi.SendJsonCommand) SendJsonCommand: http://192.168.1.11:80/api/2E0373E8F5/alarmsystems/1/config: {“code0”:“1234”}
System.Net.WebException(0x80131509): De externe server heeft een fout geretourneerd: (503) Server is niet beschikbaar.

(server is not available)

Not sure what happens here

Anyone knows why this was working and not anymore?

IDK, I don’t see change on alarm code beetween the 2 versions.
But the error “failed to set code” happen when the fonction alarmSys->setCode fail, and this one can fail, if you can’t save it or if the encryption have fail.

How could I work around this issue? Did the encryption key change between the two versions maybe? Or what are other reasons for not being able to save it?

It occurred when I upgraded to 2.13.1. I have a Conbee here on Windows that still runs v2.13.0 and alarmsystem is still functioning. I postponed upgrading this one because of this version.
Should I provoke it and upgrade the windows system also to v2.13.1?

I dived in the code, this is correct behavior but the error reason is not obvious.
v2.13.1-beta now checks that the correct libssl version is installed when setting the code and if not returns above error.

One thing I’ve noticed recently is that this also requires to have a deCONZ version installed that is compiled on recent Debian/Raspbian/Ubuntu. The versions at http://deconz.dresden-elektronik.de/raspbian are compiled with Raspbian Stretch, which was good enough for pre Alarm Systems but lack the required C++ headers of the new libssl version.

I digged a bit deeper and found another problem here. Recent OS specific versions are only available via APT currently. For upcoming v2.13.2-beta the compilation on Raspbian Stretch will be replaced by Raspbian/Debian Buster and Ubuntu Bionic version so the problem should resolve then.

On Windows the above mentioned issue shouldn’t apply, as far as I’ve seen this affects older Linux versions only due the outdated libssl versions.

Ok, thanks for that extra info that might be the cause for my Raspbee indeed. I did update to latest versions of OS at least a year ago and since then stayed away from it as the last OS update left me with a non functioning network because a deconz change on a file was undone by the update. I stayed away from updates since then,.

So a refresh of the image could help (I do have backups of the zll.db)? Or is the new beta due soon so I could skip it for now?

Will upgrade the Windows version too to check on this one then too.

Thanks!

Raspbian Buster is out since a while, you might already have it :slight_smile:

To check on the command line:

cat /etc/os-release

The easiest way to migrate to a new image is to create a backup via the Phoscon App > Menu > Gateway. And to apply that on the new installation.

It is buster alright, but guess missing the correct libssl stuff. I will plan installing the new image for next week!

Should be enough to just install deCONZ Beta via APT repository as described in: ConBee II Installation

That should get the latest version with correct compiled libssl version.

But that is what I normally do. Although I remember having to install the v2.13.0 version with wget… and now this old guy is unsure how I did the v.2.13.1… Probably the same way…
In that case I will check with the next beta and be sure to use the normal APT way

Just checked Windows install, all is good there!

1 Like

Is there a buster release yet?

I used the image quite some time ago I think? It is in the list of images?

Yes, Buster is in the APT repositories since a while. But the Raspbian version for manual download is compiled on Stretch (since this is upward compatible with newer distros), but this has become problematic for Alarm Systems since the libssl version in Stretch is too old.

I guess i have the same issue. First time setting it up:

curl https://phoscon..net/api/**/alarmsystems/1/config -k -X PUT -d ‘{“code0”: “1234”}’ [{“error”:{“address”:"/alarmsystems/1",“description”:“internal error, failed to set code, occured”,“type”:901}}]% (edited)

(deconz beta on docker)