search

FlyingDiver / Indigo-radiora2

Indigo plugin for Lutron control systems. Works with Radio Ra 2, Radio Ra Select, Homeworks QS, and Caséta
MIT License
6 stars 3 forks source link

Battery status? #46

Closed FlyingDiver closed 3 years ago

FlyingDiver commented 3 years ago

https://forums.indigodomo.com/viewtopic.php?f=217&t=24475

I have several groups of Serena shades working with the plugin. I also have a remote. (So at this point, all my Lutron devices are battery powered.)

I noticed in the release notes for a recent update of the Lutron IOS App that it mentions "Caseta and RA2 Select now have Low Battery Alerts in the app. Be alerted if your battery runs low for Picos, Shades, and Occupancy Sensors!".

So if the app can do this, is it possible for the plugin to do it as well? Ideally, I'd love to see the battery state of Lutron devices from within Indigo. Or at least to be able to attach a trigger to a low-battery warning event.

FlyingDiver commented 3 years ago
Screen Shot 2020-10-22 at 4 16 03 PM
gt3mike commented 3 years ago

Looking forward to seeing whether this works in RR2 and not just RR2 Select!

FlyingDiver commented 3 years ago

I'm going to need some testers, since I don't have any battery shades.

gt3mike commented 3 years ago

Me either. But I have plenty of Picos and sensors.

On Thu, Oct 22, 2020 at 2:50 PM Joe Keenan notifications@github.com wrote:

I'm going to need some testers, since I don't have any battery shades.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FlyingDiver/Indigo-radiora2/issues/46#issuecomment-714753936, or unsubscribe https://github.com/notifications/unsubscribe-auth/AINFBCHS35WUVP6E3YASTUTSMCLHRANCNFSM4S3VWKIA .

rapamatic commented 3 years ago

It seemed to work for me. I have a battery powered roller that is device ID 18, here is what I got back when I sent a battery request command. I don't understand the date in the return string, especially since the integration ID 18 is one I've had longer than integration ID 60. 

Oct 22, 2020 at 3:55:19 PM
   Action Group                    Shade status test
   Lutron RRA2/Caséta Debug       Lutron Main Repeater #1 Downstairs: Sending command: '?DEVICE, 18, 1, 22'
   Lutron RRA2/Caséta Debug       Sent Raw Command: '?DEVICE, 18, 1, 22' to gateway 402305932
   Lutron RRA2/Caséta Threaddebug Lutron Main Repeater #1 Downstairs: 50 characters read:
~DEVICE,18,1,22,0x011E0AE1,1,1,06/16/2019 14:18:38
   Lutron RRA2/Caséta Threaddebug Lutron Main Repeater #1 Downstairs: 9 characters read:

GNET> 
   Lutron RRA2/Caséta Threaddebug Lutron Main Repeater #1 Downstairs: self.buffer = 'GNET> ~DEVICE,18,1,22,0x011E0AE1,1,1,06/16/2019 14:18:38 
GNET> '
   Lutron RRA2/Caséta Threaddebug Lutron Main Repeater #1 Downstairs: msg = 'GNET> ~DEVICE,18,1,22,0x011E0AE1,1,1,06/16/2019 14:18:38 
'
   Lutron RRA2/Caséta Threaddebug Lutron Main Repeater #1 Downstairs: self.buffer = 'GNET> '
   Lutron RRA2/Caséta Threaddebug Received command: GNET> ~DEVICE,18,1,22,0x011E0AE1,1,1,06/16/2019 14:18:38 from Gateway 402305932
   Lutron RRA2/Caséta Threaddebug Received a Device message: GNET> ~DEVICE,18,1,22,0x011E0AE1,1,1,06/16/2019 14:18:38

And here is from sending the command to a different battery shade:

Action Group                    Shade status test
   Lutron RRA2/Caséta Debug       Lutron Main Repeater #1 Downstairs: Sending command: '?DEVICE, 60, 1, 22'
   Lutron RRA2/Caséta Debug       Sent Raw Command: '?DEVICE, 60, 1, 22' to gateway 402305932
   Lutron RRA2/Caséta Threaddebug Lutron Main Repeater #1 Downstairs: 50 characters read:
~DEVICE,60,1,22,0x011E2A64,1,1,04/24/2016 14:51:30
   Lutron RRA2/Caséta Threaddebug Lutron Main Repeater #1 Downstairs: 9 characters read:

GNET> 
   Lutron RRA2/Caséta Threaddebug Lutron Main Repeater #1 Downstairs: self.buffer = 'GNET> ~DEVICE,60,1,22,0x011E2A64,1,1,04/24/2016 14:51:30 
GNET> '
   Lutron RRA2/Caséta Threaddebug Lutron Main Repeater #1 Downstairs: msg = 'GNET> ~DEVICE,60,1,22,0x011E2A64,1,1,04/24/2016 14:51:30 
'
   Lutron RRA2/Caséta Threaddebug Lutron Main Repeater #1 Downstairs: self.buffer = 'GNET> '
   Lutron RRA2/Caséta Threaddebug Received command: GNET> ~DEVICE,60,1,22,0x011E2A64,1,1,04/24/2016 14:51:30 from Gateway 402305932
   Lutron RRA2/Caséta Threaddebug Received a Device message: GNET> ~DEVICE,60,1,22,0x011E2A64,1,1,04/24/2016 14:51:30
FlyingDiver commented 3 years ago

Any chance those are the dates you last changed the batteries?

FlyingDiver commented 3 years ago

I'm trying to figure out where in that string is the battery status.

~DEVICE,18,1,22,0x011E0AE1,1,1,06/16/2019 14:18:38

rapamatic commented 3 years ago

It is conceivable, depending on how carefully they calculate that - we recently repainted the room that the integration ID 18 shade is in, and the batteries were out of the shade for a few days. I put the same ones back in, so maybe it didn't detect that as a change...

I honestly don't remember when I last changed batteries - the shades are pretty incredible in that regard.

FlyingDiver commented 3 years ago

I'm just thinking that they might remember when they last lost power, which could be a change indicator.

rapamatic commented 3 years ago

Thinking about it more, that could be the last date that the battery status changed (e.g. from low state to normal state...)... because since I just took out the batteries when I repainted the room and put them back in, the shades would not have registered a low charge state....

FlyingDiver commented 3 years ago

Well, it's gotta be one of the two fields immediately after the device address. Hmmm.

FlyingDiver commented 3 years ago

Ah. This page is for the temperature sensors (for the HVAC controller), but I bet it's the same data.

Screen Shot 2020-10-22 at 5 43 37 PM
rapamatic commented 3 years ago

I'm trying to figure out where in that string is the battery status.

~DEVICE,18,1,22,0x011E0AE1,1,1,06/16/2019 14:18:38

Yeah, it is tricky since they don't document this function... If I had some spare almost dead D-cells I could try swapping them out... or maybe removing one battery? I don't know what the voltage is that triggers a low voltage state...

rapamatic commented 3 years ago

Ah, I should have thought to look at the wireless temp sensor response. That makes sense. So like I guessed, the date is the last time the status changed...

FlyingDiver commented 3 years ago

Here's the result for a hardwired shade: ~DEVICE,128,1,22,0x00BB13B1,2,1,01/01/2000 00:00:00

FlyingDiver commented 3 years ago

So, yeah, I can do something with that.

rapamatic commented 3 years ago

I can confirm that I get the same response from a hardwired shade

~DEVICE,128,1,22,0x01EE87EB,2,1,01/01/2000 00:00:00

rapamatic commented 3 years ago

I wonder what the point is of the hex number in the response?

FlyingDiver commented 3 years ago

I think that's the MAC/HW Serial number of the device.

gt3mike commented 3 years ago

Do you think this will work for Picos and sensors too, or just shades?

On Thu, Oct 22, 2020 at 3:57 PM Joe Keenan notifications@github.com wrote:

I think that's the MAC/HW Serial number of the device.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FlyingDiver/Indigo-radiora2/issues/46#issuecomment-714785078, or unsubscribe https://github.com/notifications/unsubscribe-auth/AINFBCF7KLUNEE6N2Y3AZ2DSMCTDNANCNFSM4S3VWKIA .

FlyingDiver commented 3 years ago

I just tested the query command with both a motion sensor and a Pico, and got the same kind of results back. So yeah, probably will work.

FlyingDiver commented 3 years ago

Since I'll have to specifically poll for this data, how should I schedule that?

FlyingDiver commented 3 years ago

Test version available: https://github.com/FlyingDiver/Indigo-radiora2/releases/tag/7.4.0

I punted on the scheduling of the update, and made an Action that does it. So just use the Indigo scheduler to update the battery levels as you want.

rapamatic commented 3 years ago

That makes sense. I’ll test tomorrow.

FlyingDiver commented 3 years ago

Note that it polls all the possible battery devices (Picos, Sensors, Shades) and adds the battery level property to each that reply that they're using battery. So they show in the UI.

Weird note is that I have to do each Pico button individually, so they all show that UI. At some point it might make sense to go back and create device groups for keypads to group the buttons. I think that can be done without breaking back compatibility. I need to try that to see.

gt3mike commented 3 years ago

Any idea whether this is dependent on any particular RR2 firmware version?

FlyingDiver commented 3 years ago

It probably is, but I have no idea how to tell which ones. That would require digging through the release notes.

FlyingDiver commented 3 years ago

All the testing I'm doing is showing that this is working properly, and @rapamatic is seeing the same results. I'm going to let this bake for another day or two before releasing. I'm going to take a look at the other open issues before I do.

FlyingDiver commented 3 years ago

Release 7.4.0. Updated store.