Set armed/bypass state for HRSD1 using a scene...

Community Playground General Discussions
1

I’m sure this isn’t that hard, but it doesn’t seem like others are doing it, and being cautious, thought I’d ask if there’s a sample of this sort of thing about–my searches haven’t hit any, but my searches may be ham-handed.

Now that I’ve got the doorbell sensor working, and have a scene set up to send us Prowl alerts when the button gets pressed IFF the HRSD1 in that circuit is armed, I’d like to be able to arm/disarm the sensor through SQC. I don’t see a way to do that, save through a scene control…in this case, two, no doubt.

–Richard

2

[quote=“rlmalisz, post:1, topic:168493”]I’m sure this isn’t that hard, but it doesn’t seem like others are doing it, and being cautious, thought I’d ask if there’s a sample of this sort of thing about–my searches haven’t hit any, but my searches may be ham-handed.

Now that I’ve got the doorbell sensor working, and have a scene set up to send us Prowl alerts when the button gets pressed IFF the HRSD1 in that circuit is armed, I’d like to be able to arm/disarm the sensor through SQC. I don’t see a way to do that, save through a scene control…in this case, two, no doubt.

–Richard[/quote]

Actually, on thinking about this some more, a better approach is probably to muddle up a virtual binary switch of sorts that gets its current state by querying the armed state from the HRSD1, and upon toggle, sends the appropriate command to the HRSD1. This should be doable, right? And if done correctly, wouldn’t take much modification to adapt for locks? I guess the “device” could even have a variable that can be set to the correct URN and serviceId for the armed/disarmed device and its attributes, making it a generic arm/disasm binary switch. Would be lovely to be able to create those as required, and then suck them into SQC.

–Richard

3

[quote=“rlmalisz, post:2, topic:168493”][quote=“rlmalisz, post:1, topic:168493”]I’m sure this isn’t that hard, but it doesn’t seem like others are doing it, and being cautious, thought I’d ask if there’s a sample of this sort of thing about–my searches haven’t hit any, but my searches may be ham-handed.

Now that I’ve got the doorbell sensor working, and have a scene set up to send us Prowl alerts when the button gets pressed IFF the HRSD1 in that circuit is armed, I’d like to be able to arm/disarm the sensor through SQC. I don’t see a way to do that, save through a scene control…in this case, two, no doubt.

–Richard[/quote]

Actually, on thinking about this some more, a better approach is probably to muddle up a virtual binary switch of sorts that gets its current state by querying the armed state from the HRSD1, and upon toggle, sends the appropriate command to the HRSD1. This should be doable, right? And if done correctly, wouldn’t take much modification to adapt for locks? I guess the “device” could even have a variable that can be set to the correct URN and serviceId for the armed/disarmed device and its attributes, making it a generic arm/disasm binary switch. Would be lovely to be able to create those as required, and then suck them into SQC.

–Richard[/quote]

So are there known issues with trying to send a command to a battery-powered device, such as an HRSD1? I have cabbaged together a D and I file for setting (and displaying) the armed status of one of these things via a Binary_Switch. When I press either the “on” or “off” buttons, I get the beloved “delivery failed” error dialog. If I paste the set command into the LUA test window:

luup.call_action("urn:upnp-org:serviceId:SecuritySensor1","SetArmed",{ newArmedValue="1" },26)

And hit “go”, it displays that it all went fine. I am starting to think this window is a placebo.

For these devices, do I need to implement some sort of retry loop? FWIW, I am observing that when I hit the “arm” button for the sensor in UI4, it’s sometimes several minutes before the value of the “armed” variable changes, and UI shows the “armed” button as highlighted.

–Richard

4

I use the armed state of my front door (HRDS1) as an Away state instead of a virtual device for couple years now. Works great and more reliable than virtual device… I can post the luup command once I get home.

5

And BTW, you don’t worry about battery because armed state is inside Vera and not the sensor.

6

Thanks. Got it working–was using the wrong urn. I now have a functional “binary light” device that displays the armed state of the doorbell sensor and allows me to change it through SQC. And have a scene working where if this sensor is armed and the doorbell rings, we get a Prowl alert to our i*. Just got done closing up the project box for the electronics to make a momentary energization of the doorbell circuit hold a NC relay open long enough for an HRSD1 to decide it’s tripped. And got it mounted in the tiny hall closet, where it will live out its days.

Enough nerding out for today. Off to the nursery, and thence, probably to digging large holes in the ground. Thanks for your help.

–Richard

7

Right, SecuritySensor1 is not from upnp namespace (surprisingly), but from micasaverde one - urn:micasaverde-com:serviceId:SecuritySensor1

Here are my Luup snippets (device # is 27):

  1. Reset (i.e. set to Bypass) the sensor:
luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1", "Armed", 0, 27)
  1. Read the current state (0 = Bypass, 1 = Armed):
local AwayStatus = luup.variable_get("urn:micasaverde-com:serviceId:SecuritySensor1", "Armed", 27)
8

[quote=“rlmalisz, post:1, topic:168493”]I’m sure this isn’t that hard, but it doesn’t seem like others are doing it, and being cautious, thought I’d ask if there’s a sample of this sort of thing about–my searches haven’t hit any, but my searches may be ham-handed.

Now that I’ve got the doorbell sensor working, and have a scene set up to send us Prowl alerts when the button gets pressed IFF the HRSD1 in that circuit is armed, I’d like to be able to arm/disarm the sensor through SQC. I don’t see a way to do that, save through a scene control…in this case, two, no doubt.

–Richard[/quote]

Referring to this thread, http://forum.mios.com/index.php?topic=3010.0
Anyone able to upload some pictures/schematics/partslist?

9

[quote=“denix, post:7, topic:168493”]Right, SecuritySensor1 is not from upnp namespace (surprisingly), but from micasaverde one - urn:micasaverde-com:serviceId:SecuritySensor1

Here are my Luup snippets (device # is 27):

  1. Reset (i.e. set to Bypass) the sensor:
luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1", "Armed", 0, 27)
  1. Read the current state (0 = Bypass, 1 = Armed):
local AwayStatus = luup.variable_get("urn:micasaverde-com:serviceId:SecuritySensor1", "Armed", 27)

Yes. Your earlier post about the “armed” state being maintained inside Vera as opposed to being an attribute of the physical device makes this make all the sense in the world. That’s why they’ve got a “D_” file for these devices–they’ve wrapped them so they could add a little extra functional sugar.

–Richard