Wow, I was gone a few days and this forum thread went crazy. Looks like a lot of work going on.
I wanted to comment that being a UPB provider, I would consider you guys - Glenn, 123Taras, JamesHilliard, and bbrendon - UPB experts. It’s been years since I got down into these low level details and it’s been a long time since I’ve talked with anyone who has as well. In fact, in many respects, you’re probably more up to date than I am, as it’s been so long since I’ve dived this deep. So, don’t discount your level of expertise - it’s much greater than almost anyone else out there.
A couple of things, then I’m going to shut up and stay out of your way (I’ll be happy to help out with documentation and can try to answer any questions I can, but you guys are already pretty advanced - and if anyone needs help with products to test with, let me know). There’s another System document you guys might want to look at, if you haven’t already. This is the PIM System Description document. This is where you can find the detailed description of Pulse and Message modes, plus lots more information. For example, there is a way to get signal level and noise information even when in Message mode. You can download from the PCS website or I can get you a copy - just let me know.
I know there is a desire by some to use Pulse mode, in order to simplify device discovery - a very laudable goal. However, using Pulse mode adds a lot of overhead to the code and project - I would suggest at least starting in Message mode and get something workable, which appears to be the way Glenn is approaching it with his implementation, and then later move to Pulse mode to simplify operation, if so desired.
There was some discussion about reading device registers on individual devices in order to get more detailed information, for example which devices belong to which links (scenes - we used the terms links for so long, it’s hard to break). A big issue with this would be determining what registers to read for this information. The main registers for NID, MID, PID, Firmware Version, Network name, network password, etc - will have good consistency between products and manufacturers, but once you get past those, the registers are going to be different depending on the type of unit, the manufacturer of the unit, whether it is single or multichannel, etc. So, you would need to read the MID and PID, then have a table showing what registers to read for those devices. It’s going to get complicated and trying to get that information from most of the manufacturers is going to be problematic for multiple reasons. It could be reverse engineered but that’s going to take quite a bit of time and effort, plus you would need sample units of all desired units.
And, all of this information is already included in the Upstart UPE file. So, again, I would encourage an initial faster development that pulls that information from the UPE file then enhance it later if so desired as part of a discovery process.
I know practically nothing about HASS. I did just bring up a RPi4 with HASS and will integrate Glenn’s implementation shortly so I can play with it. bbrendon has been a huge help - thanks so much. I won’t be able to contribute, but at least I can start playing with HASS and UPB.
Now, I’ll get out of your way and try to shut up. If I can help any, let me know. Also, as this comes together, I’ll work on offering a special product discount code for HASS users to purchase product at a nice discount. bbrendon asked the moderators about this and they seem to be fine with it.
.
