02-19-2018, 12:05 PM
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82
02-20-2018, 06:30 PM
OK, I've got the Aeon multi-sensor fully working. I've been using it as the annoying test case, since it involves a good bit of stuff. I was having various problems, but assumed it must work correctly, so I kept banging away until I found all of the issues. So it was a good test case. I wasted too much time on the fact that I interpreted a number 0001B in the in the sensor docs as the hex value 0x1B, when it means 0001 binary. So I was not getting the correct bits set to make the sensor send out the right motion notifications. I also wasted time because this guy has a hierarchy of preferences for who he will send the motion sensor notifications to. Strangely, the top-most one is the one that you configured the unit to send wakeup notifications to. They weren't coming to me because I guess the master was a higher priority. That led me to figure out I'd not got the wakeup interval part of the auto-config done. So I got that done and finally it's sending me motion notifications.
The multi-sensor is working through a generic handler, with the device info file telling it what types of sensors are available. So that should be capable of handling various others of similar ilk correctly.
One big thing I've done over the last day plus is that I needed a way to tell commands that, even though this unit is not a live listener, than I know it's awake right now. Various of them have a button press sequence that will make them wake up for a while, or right after you put the batteries in they will stay awake. Doing setup is much easier if you can take advantage of that. Else you have to queue up all of the msgs and then make it do a wake-up.
In the client interface, in any of the commands that query info or send manual commands like setting associations or config parameters and such, if I see it's a non-live listener, I can have a check box for 'I know it is awake' that you can check to make the msgs get sent right then.
It got a little confusing at first, because there's doing things async, which means that the driver just queues up the msgs and returns, and then there's whether it's a live listener or not. I'd sort of gotten those confused in the early design. You may want to do something non-async because you need to get the response right then, to return it to the client interface generally. And you may want to just queue up a set of commands to be sent, such as with auto-config. But, separate from that is whether the unit is awake or not.
If it's a non-listener and not awake, then any command that requires an immediately response is going to fail. That's the one unsupportable variation. But the other scenarios are all useful. Do it async, i.e. have them queued up for send ASAP but return immediately. Do it async, but we know it's a non-listener and not awake so they will be queued up to be sent the next time the unit wakes up. Or it's a listener, but we may want to just queue them up or we may want to wait.
I can now support all of those as required. That's definitely sped up my testing cycle a lot having those, and now having plenty of info querying commands.
Anyhoo, now finally back to the Fibaro to make sure all that color lighting stuff is back working...
The multi-sensor is working through a generic handler, with the device info file telling it what types of sensors are available. So that should be capable of handling various others of similar ilk correctly.
One big thing I've done over the last day plus is that I needed a way to tell commands that, even though this unit is not a live listener, than I know it's awake right now. Various of them have a button press sequence that will make them wake up for a while, or right after you put the batteries in they will stay awake. Doing setup is much easier if you can take advantage of that. Else you have to queue up all of the msgs and then make it do a wake-up.
In the client interface, in any of the commands that query info or send manual commands like setting associations or config parameters and such, if I see it's a non-live listener, I can have a check box for 'I know it is awake' that you can check to make the msgs get sent right then.
It got a little confusing at first, because there's doing things async, which means that the driver just queues up the msgs and returns, and then there's whether it's a live listener or not. I'd sort of gotten those confused in the early design. You may want to do something non-async because you need to get the response right then, to return it to the client interface generally. And you may want to just queue up a set of commands to be sent, such as with auto-config. But, separate from that is whether the unit is awake or not.
If it's a non-listener and not awake, then any command that requires an immediately response is going to fail. That's the one unsupportable variation. But the other scenarios are all useful. Do it async, i.e. have them queued up for send ASAP but return immediately. Do it async, but we know it's a non-listener and not awake so they will be queued up to be sent the next time the unit wakes up. Or it's a listener, but we may want to just queue them up or we may want to wait.
I can now support all of those as required. That's definitely sped up my testing cycle a lot having those, and now having plenty of info querying commands.
Anyhoo, now finally back to the Fibaro to make sure all that color lighting stuff is back working...
02-20-2018, 06:49 PM
Oh, and apparently there's a later version of this guy that DOES support multi-channel. But I can't find any information about it.
02-20-2018, 10:04 PM
Didn't have time to dive back in the Fibaro tonight, so I did the battery support. If the device supports battery level, it will get picked up automatically and added. No support needed by the individual unit handlers, so no redundant code or extra effort.
02-21-2018, 09:13 PM
I had to spend some time today on the Lutron HWs client side driver for the Acme guys, as my validation of entered data was overly aggressive. That required setting up a 5.2.10 build to patch.
But I got a lot done on the Z-Wave driver as well. I got mostly through getting the Fibaro back up and going again under the latest regime. I need to work out for sure the config parameters, which are semi-incomprehensible. I've genericized the RGBW unit handler I created for this guy, so that it should probably work for at least some other units of similar ilk.
But I got a lot done on the Z-Wave driver as well. I got mostly through getting the Fibaro back up and going again under the latest regime. I need to work out for sure the config parameters, which are semi-incomprehensible. I've genericized the RGBW unit handler I created for this guy, so that it should probably work for at least some other units of similar ilk.
02-22-2018, 06:52 AM
(02-21-2018, 09:13 PM)Dean Roddey Wrote: [ -> ]But I got a lot done on the Z-Wave driver as well. I got mostly through getting the Fibaro back up and going again under the latest regime. I need to work out for sure the config parameters, which are semi-incomprehensible. 
Yeah, I just re-read the RGBW controller documentation, considering using the unit for the sensor capabilities. The documentation was written by an engineer that does not appear to communicate with non engineering type humans. Of course if you buy one of their controllers then all the config mojo is exposed in the user interface.
 
Dean here's a link to some additional documentation that might help. There is more real world use documentation in this write up.  
What's not clear to me is whether the RGBW channels can also be configured as analog sensors.  The opening paragraph last sentence of the document says yes "All IN and OUT
terminals may be user configured for LED control or 0V-10V signal readouts." but elsewhere it seems to contradict that statement.  Well even if it is only the 4 inputs it is still more cost effective than 4 separate door/window sensors. (I guess I would have to translate a voltage level) This is all predicated on whether the 4 inputs can provide their status independently back to CQC...
And oh wow, just read that this can also monitor power consumption.
-Ben
02-22-2018, 10:01 AM
The driver isn't going to support anything but its use as an RGBW controller, at least initially. The auto-config will set it up for that.
02-23-2018, 10:02 PM
The Fibaro seems to be working fine now. You can set individual color components or the color as a whole as HSV (as per the CQC V2 colored light device class), and you can do overall dim and off/on.
I did a bunch of refinement today based on lessons learned and started working towards the client side driver. This one will be considerably more extensive than the old one, so I need a good communications scheme between them. So I'm working out something nice and flexible. And of course maybe down the line we move it up to being a master controller as well, which would require even more so.
But it's feeling pretty tight. I'm banging through scenarios repeatedly to test things and nothing is ever failing.
I did a bunch of refinement today based on lessons learned and started working towards the client side driver. This one will be considerably more extensive than the old one, so I need a good communications scheme between them. So I'm working out something nice and flexible. And of course maybe down the line we move it up to being a master controller as well, which would require even more so.
But it's feeling pretty tight. I'm banging through scenarios repeatedly to test things and nothing is ever failing.
02-24-2018, 06:07 AM
Great news Dean, congratulations! For the Fibaro RGBW will we be able to send and Invoke command for "non standard" things like triggering the specialty lighting effects that are built into the unit? Can the white and color be independently dimmed?
02-24-2018, 10:34 AM
I'm supporting the Fibaro via a generic RGBW unit handler, so it wouldn't have any means to access those specialty types of things. Though I could go back and do a special handler just for the Fibaro, I'm trying to avoid that as much as possible. And I think that setting those means taking it out of the RGBW mode that the driver requires to control it.
You can set color and white separately. There is a 'SetComp' field that lets you pass values like "Green 25" or "White 50" to set the percentage level of specific color components. And you can set the color as HSV which lets you set a specific hue at a specific brightness. And there is a standard V2 dimmer field which will just adjust the overall brightness of whatever is currently active.
Of course if you wanted to do something like slowly rotate through colors or something, you could write a simple Event Monitor that could do that. Or I could write one that ships with CQC.
You can set color and white separately. There is a 'SetComp' field that lets you pass values like "Green 25" or "White 50" to set the percentage level of specific color components. And you can set the color as HSV which lets you set a specific hue at a specific brightness. And there is a standard V2 dimmer field which will just adjust the overall brightness of whatever is currently active.
Of course if you wanted to do something like slowly rotate through colors or something, you could write a simple Event Monitor that could do that. Or I could write one that ships with CQC.