I’ve been looking through the source code of Premise’s UPB driver and there appears to be some commonality on how it extracts a device’s default faderate and reportstate settings for both PCS and SA. It uses a mask of 0x10 and 0x0F respectively. I don’t know (yet) where it got the value that it’s masking but the fact the masks are identical seems promising.
Feature Request for two new attributes indicating the device’s default fade-rate and if it is programmed to report its state when it is manually operated. As mentioned in one of my previous posts, I find these two properties useful to see (without having to use UPStart to check them).
Ok, finally had a few minutes to look for this information. Both items - whether the device is programmed to report its state when operated manually and the device’s programmed fade rate, are stored in a byte called “Dimmer Options”. The report state feature is stored in bit 4 of the byte ( 0 - means don’t transmit, 1 - transmit report). The programmed fade rate is stored in bits 0 - 3. On both the SAI US2-40 and our SW-7, this byte is located at memory register 0x8D. The default value for this register - out of the box - is 0x83.
What happens when the fade rate is higher than 15? Is there a way to select the default fade rate, which is required in packets that have a channel since those types of packets require that a fade rate is specified.
If I recall what the UPB Command Wizard states, if no fade rate is supplied then the device uses its default fade rate. I don’t believe there’s an actual value that can be used to indicate “use your default fade rate”.
No idea what happens if fade rate is > 15. I’ll have to try it.
That’s a good question on what happens when a fade rate higher than 15 is provided - I’m not sure. If I had to make a wild guess, I would guess that it defaults to FF. When I can find a minute, I’ll try to test it.
However, I’m pretty sure that when you specify a fade rate in a command, if you use FF for the fade rate, it will use the default fade rate as specified in Upstart for that device. So for instance, on a GOTO command, you could do something like
87000101FF2264FFxx
where the last FF would be the default fade rate for the device and the last xx is the checksum. I’ll try to test and confirm that also.
0xFF is definitely not 0-15 so I’d say that’s a good way to indicate “use default fade rate”.
EDIT
There’s so much information in the Premise UPB driver’s source code that it’s challenging to get one’s arms around it. I looked at it again and discovered it also uses 0xFF (255) to represent ‘default fade rate’.
The fact it is in upbCommon.h indicates the fade_rate table is common to both PCS and SAI (the two manufacturers the driver supports) and, as stated by webmtn, for Web Mountain as well.
I switched the release to beta status. I’ll be offline for the next couple of weeks – a good time to test out what is there and think up features that are missing and features that would be nice to have. I’m happy to keep making this thing better. Check out the README for both the library and for the Home Assistant plugin.
And, thanks to everyone who has been testing and requesting features. The collaboration really helped create something that works well! A special shout out to @123 and to @webmtn for your help!
Many thanks to you Glenn for putting hammer to nail and building this long-requested integration. It was a pleasure working with you and I wish you an enjoyable vacation.
BTW, I’ve exercised one or two of the newer services but simply haven’t gotten around to reporting the results (all successful).
One more comment. We had discussed how memory registers beyond the core would be different between manufacturers. I spent a little time looking at memory registers between my switches (Web Mtn) and SAI’s switches. We’re actually very close but there are some differences. And, I’m betting that there will be a lot of similarity between the two of us and PCS. However, where one really big difference will be is with respect to the Transmit component tables. With us (WebMtn) and SAI having interchangeable faceplates, while PCS doesn’t, how these interchangeable faceplates work causes dramatic differences between our devices and PCS. The Receive components will probably be pretty close, but every manufacturer has some other differences that will impact the memory map. For example, SAI has a feature on the US2-40 where with a particular button tap sequence, you can manually link a transmitter and a receiver. In my case, when we implemented Gen2 on the SAI hardware, we didn’t have enough room in memory for everything and had to remove some functionality - this is one feature that didn’t make it into our devices.
Similarly, PCS has a feature where you can select receive sensitivity (basically just an attenuator). We and SAI don’t have that feature. So, I’m revising my earlier comment to say that there will probably be some pretty good commonality in the memory registers, but be careful as all the vendors have slightly different feature sets that will impact the memory map.
I also want to thank Glenn, 123Taras, bbrendon, and jameshilliard - especially Glenn and all his hard work. I’m astounded what has happened with this in a very relatively short period of time. I’m a complete newbie with Home Assistant and I’ve barely found time to get it loaded onto a Raspberry PI 4 and get configurator and Samba loaded and working. So, I’m way behind all of you but hope to get to a point soon where I can play with this beta integration.
For example, 4/29 is a US240 and it is a switch. If you have similar for your products I can add. The table you see there comes right out of the protocol manual on the PCS site.
Where the format is not number/number (e.g.: WMT/88) its because I don’t know the vendor number so I used an abbreviated vendor name. The code to translate in that case will not recognize the device name (the device should still work). I use the table to give each device a pretty name – nothing more.
Thanks for the offer, Glenn. Yes, I would like to provide you with my product details and I have a lot to provide. The ones listed for me are actually PCS products that I no longer sell. I’ll get you my list in a couple of days.
A couple of clarifications. The first number, using your example of 4/29, is what is called the Manufacturer’s ID. Here is that listing:
MID
PCS 001
MD Mfg 002 (I don’t think MD offers any of these products anymore and hasn’t for years)
WMT 003
SAI 004
HAI 005
And, there’s some more but they probably aren’t worth listing, just like the MD Mfg units are probably not worth listing. I would list PCS, WMT, SAI, and HAI.
So, you can replace the names with these numbers as the first part of that combination. These are unique - for example, only WebMtn products have a MID of 3.
The second part is what is called the Product ID. this is an ID that the manufacturer has given to the product. It was often assigned sequentially - the first product that was done used 001, the second was 002, and so on. Mine were not assigned in that manner, but these can be reused by the manufacturers. So, I can have a product with a product ID of 5, so can PCS, and they probably won’t be the same product. What makes them unique is the MID.
So, just as you are doing, Upstart reads these values and then uses a table to determine what the product is. For example, if you see a MID of 3 and PID of 5, then it’s a WebMtn Appliance Module.
These are the products I update with Gen2 firmware. I sell most of the other SAI devices and some PCS devices, but they are not modified and Upstart would see them as SAI and PCS units, even though I give some of them a different model number.
