Hi @BobA First, I’d like to say ‘thanks’ for this binding. It was one of the reasons I opted to go with OH in the first place.
I can’t really say this is a bug - I’m not using this in the intended way - but I hope that maybe you can tell me what’s going on, and perhaps this new 2.5.5 binding could be adapted to this use case.
A little background. I have two OH installations, and that’s the crux. The first is an Openhabian install that started with the 1.8 binding, directly connected to an AD2USB on a 128BPT panel. I recently installed OH in a docker container on another machine to do more “heavy lifting” than what I can do solely on the Pi, and it’s in connecting these two that something interesting happens…
I believe that in the 1.8 binding, I had to connect the AD2USB via the TCP setting and run ser2sock. No problem. I have had that working for some time. However, as an experiment, I set the OH install in the Docker with the 2.5.5 binding to try and read the TCP information from the 1.8 binding on the Pi connected with the AD2USB. It worked. Very cool. I don’t have to set up some MQTT-based interface between the two installations…
Then I went ahead and just upgraded to the 2.5.5 binding on the Pi. It works on the Pi. However, I now get the following error in the logs on the Docker container:
Error Invalid number of parts in keypad message while parsing message [10000001100000003A–],003,[10[10000001100000003A–],003,[f70700060003001c28020000000000],"DISARMED READY TO ARM ". Please report bug.
While the binding is not set to be used this way, I am very curious if there’s a way to check the parsing and not throw an error, which will effectively make a single installation of an AD2USB available over the network to other OH installations. I’m working on a redundancy/failover strategy (and some test installs) with multiple OH installations, so this would allow for a lot of reuse if it’s an easy use case to manage.
Purely as an aside,completely off-topic,and I’m probably the only OH user with this situation, there are some limitations on this 128BPT panel (outside of the scope of your binding) in that outside of the initial zones on the panel, all expansions utilize the V-Plex bus. Ultimately I’m going to have to purchase another AD device (USB, HAT, etc) to read that bus independently, but I digress… Since I can create multiple bridges easily with your 2.5.5 binding, I think this is going to be really interesting to monitor multiple V-Plex zones in multiple buildings. Very helpful binding, and I appreciate your work on this.