How to create virtual devices / state machines?

[cboles]

Hi everyone-

I'm new to HSPRO, but not to programming or doing custom automation coding. I have a live / work building I am setting up with about 80 Z-wave devices including lighting, HSM100 sensors, door sensors, HVAC, etc. I apologize ahead of time if this has been covered elsewhere, but I don't know the search keywords in order to find it.

My problem is that I'm finding that taking various sensor and device events along with time-of-day info, applying boolean logic and then directly controlling other devices makes for awkward programming, and can't easily accomplish what I want (at least as far as I can tell). Here is an example problem I would like to solve:

Consider the following Z-wave devices:

• stairway light (switch at top)
• HSM100 sensor at lower entry
• door sensor at lower entry
• door sensor at top of stairs

The desired behavior is this:

• if anyone is "present" at the top or bottom of the stairs, and it is dark (typically night), turn the light on
• "presence" in these case being the opening of either door, motion detection, or the act of turning on the light switch manually
• turn the light off some amount of time after the last indication that someone is present

I can accomplish this to some degree right now using events with HSPRO, but it leaves a bit to be desired. I use both door sensors, the time of day, and the HSM100 motion detection to turn the light on, but I essentially rely on the delayed off features of the HSM100 to ultimately trigger an event and turn the light off. If someone manually turns on the light, or never goes all the way down the stairs where the HSM100 sees them, the lights won't turn off.

The simplest solution I can think of is some sort of script or code that manages the light so that many events from the individual sensors can turn the light on, but an internal timer in the script ultimately turns the light off if no new turn on events come in. My door sensors have no delayed off, so they need this. Even the HSM100 delayed off, IMHO, should not really be used for controlling the timing of light turn off. That signal should just be for motion. The amount of time that various lights are left on should be independently controllable - not part of the sensor timing.

What I would really like to do is create a number of virtual "devices" that are run by scripts that have state variables and can act as state machines. With these I can create abstract devices like "someone is in the stairway" that integrate information from various sensors, passage of time, and other contextual information. The state change events of "someone is in the stairway" can then in turn trigger a "stairway light manager" device which takes the presence events along with time of day, ambient light levels, manual inputs, and time since the last event to decide if the light should be on or not.

In this way you have the ability to add a number of abstraction layers between sensors and actuators so that the two are not directly linked by boolean logic and so that the abstract devices can represent more meaningful concepts like "someone is in the stairway" from which it is easy to create logical expressions that have obvious behavior.

Are people already doing this with HSPRO? how?

Thanks,

Colby

[NicolaiL]

Hi Colby

I understand your thinking and I am in very much the same situation. I use a mixture of HSM-100, X10 PIRs, alarm system PIRs and door contacts to detect presence around the house.

After much experience and trial and error over the years I have stopped relying on the Off signal form the PIRs (for X10 and alarm PIRs) and instead using programmed logic for this. The reason for this is that:

• X10 signals weren't reliable enough in my case. Some of them got lost resulting in the light staying on
• the alarm PIRs constantly sends on and off whenever they detect change (so if you sat still for 10secs the light would go off)

Where I'm at now is a solution with the BLRadar plug-in and some custom code. This is excellent at managing my PIRs and I have created virtual devices for all HSM-100s and alarm PIRs, although this is not necessary for my few remaining X10 PIRs.

Through BLRadar I have then set it up to NOT process Off commands, but instead rely on the time out you can set on each device. This is how I have set it up for any device that is NOT and HSM-100 as I feel I can rely on the Off signal for the HSM-100

I have written a bit of custom code (UDMC in BLRadar terms) that is called by BLRadar when a motion sensor is triggered and another piece of code that is called when Off is called (in my case through the time outs).

The On code is used to turn on the lights and I've based the light levels on a another HS device I have created (one for each room) that basically holds the desired DIM level for that room. That stops me getting blinded when I go to the bathroom in the middle of the night.

I also have another HS device per room which is controlling whether I want any action taken based on a motion commands (i.e. auto on/off, off only, no action) and the On script is using this to determine if it should actually turn the light on or not. This is helpful for rooms like bedrooms where you want the motion sensor to trigger light during day/early evening, but not during the night.

The Off script called by BLRadar is then fairly basic and basically just turns off the lights that are passed as parameters to the script.

I am finding, though, that with my increased use of HSM-100s I'll need to modify the code slightly when I find some time. The problem I have is that the HSM-100s sends ONLY one ON signal when it first detects motion and no more until it has sent an Off signal.

The problem with this is evident in the following use case:

1. You walk in to a room
2. Motion is detected, light turns On
3. 5 minutes later you walk out. You're a good citizen so you turn off the light on the switch on the wall
4. 5 minutes later you walk back in to the room
5. However, the time outs on the HSM-100 was set to 30 minutes so no off signal was ever sent. No On signal will be sent either
6. Result: you are left in darkness

You might say I should just lower the time-out for the HSM-100 to, say, 2 minutes. This would fix the above scenario, but if the room was your TV room then it is likely that you would sit still for longer than 5 minute while you catch up on your favourite soap, and that would leave you in darkness!

So, for HSM-100s I am planning to decrease the time out to maybe 5 minutes, and then have a "time out" device for the room that would be used to determine how quickly I actually wanted the room light to be turned off (might be different time out period based on time of day or what 'scene' you are running in the room). I would then use my Off script to create a delayed event that would eventually turn off the light. I would also modify my On script to remove any delayed events and effectively 'reset' the time out.

The neat thing about this is it would also allow you to create other nice features like dimming the lights by, say 50%, in the room one minute prior to actually turning the lights on, giving anyone in the room a warning and an opportunity to move about and turn the lights back on again!

Anyway, this was a much longer and involved post than I intended it to be, but hopefully some food for thought. I don't think you will get round doing some coding for this, but with a plug-in and a good architecture around it you can keep your coding to generic procedure calls that can be shared by many motion sensors.

Nicolai

[Uncle Michael]

What I would really like to do is create a number of virtual "devices" that are run by scripts that have state variables and can act as state machines. With these I can create abstract devices like "someone is in the stairway" that integrate information from various sensors, passage of time, and other contextual information. The state change events of "someone is in the stairway" can then in turn trigger a "stairway light manager" device which takes the presence events along with time of day, ambient light levels, manual inputs, and time since the last event to decide if the light should be on or not.

In this way you have the ability to add a number of abstraction layers between sensors and actuators so that the two are not directly linked by boolean logic and so that the abstract devices can represent more meaningful concepts like "someone is in the stairway" from which it is easy to create logical expressions that have obvious behavior.

Are people already doing this with HSPRO? how?

Colby,
It is certainly possible to create a device that can reflect occupancy. Of course, it will only be as reliable as the input data and the logic that control it.

I use something similar for several rooms in my house. If a motion sensor in the room is activated then the virtual device is turned on. In larger rooms and rooms with nooks and corners I may have multiple motion sensors, but all of them turn on the same virtual device. To determine "occupancy" (the holy grail of HA!) I use a very simple algorithm. Every 30 sec a script checks the aggregation device and if the device is on, the script turns if off. Then, for each room, there is an event that has a condition trigger that asks two questions: Is the light in the room on, and Has the aggregation device for the room been off for more than X minutes. If both are true, then the light gets turned off.

The keys to making this work are that there have to be sufficient sensors to give adequate coverage of the space, and X has to be chosen appropriately for the activity in the room.

In only special cases do I attempt to turn on a light when someone enters. Our floor plan is not well suited to that task, and so I have chosen to require that someone wanting the lights on to press a button. Although a serious imposition, it seems to be working ok. Of course, for your stairway example, I would probably choose to assure the light is on whenever the aggregation sensor is changed to on. So, an event with a trigger that the virtual device changes to on, and it is dark, then turn on the light.

[NicolaiL]

Colby,
To determine "occupancy" (the holy grail of HA!) I use a very simple algorithm.

Good point. BLRadar (can you tell I am a fan) has incorporated the concept of Occupancy Sensors. You simply create them and decide which of your Motion Sensors are part of any given Occupancy Sensor.

Personally I have generally managed (a couple of exceptions) to keep to a single PIR in each room but OS are definitely useful.

Nicolai

[dschoppe]

I use virutual "occupancy" devices too, one per room generally. So as an example, to handle lights in room X, based on motion sensors and entry doors, I'd have the door open and motion events both manipulate a virtual occupancy device X (vodX) as follows:

Remove delayed device actions for vodX
Set vodX on (occupied)
Schedule delayed device action to set vodX off (vacant) in N minutes.

I then control lights based on changes to the vodX occupancy device as follows:

If vodX becomes on (occupied), set lights on
If vodX becomes off (vacant), set lights off

My light switches also report instant status (and differentiate between control at the switch itself (off replied/on replied) vs HS commanding the switch (scene on/scene off). So, I have events to handle the case where a user manually turns off a light, meaning the room should go immediately vacant (ensures that re-entry to the room does the right thing, i.e., lights turn back on):

If light becomes off-replied, then:

Remove delayed device actions for vodX
Set vodX off (vacant)

Hope this isn't too confusing?

Don

[cboles]

Thanks for all of the input. I'm going to check out BLRadar as well as try writing some of my own scripts. I'm getting the impression that scripts only get called when there is an event, so that timeouts need to be implemented by scheduling a delayed action? What about making a "tick" event that happens every minute so that virtual devices can maintain their own timing? I don't know if the scripts support persistent variables yet (I'm hoping they do) so that one can keep track of state and time delays between ticks.

[Uncle Michael]

I'm getting the impression that scripts only get called when there is an event, so that timeouts need to be implemented by scheduling a delayed action? What about making a "tick" event that happens every minute so that virtual devices can maintain their own timing? I don't know if the scripts support persistent variables yet (I'm hoping they do) so that one can keep track of state and time delays between ticks.

There are three concepts that may be useful here.
-One is that all devices maintain their own virtual clock, so you can query the time that has elapsed since their last state change.
-Two: Each device has a value associated with it. One use you can put that value to is as a storage location.
-Three: "Events" can be triggered by elapsed or absolute time or by a time condition. You can have a recurring event, for example, every minute, every 10 seconds, or every 13 minutes and 22 seconds, or at 9:47 every Monday, or if a device has been in an 'Off' state for longer than x minutes. You do not have to depend on a physical event to call a script.

[mfisher]

Thanks for all of the input. I'm going to check out BLRadar as well as try writing some of my own scripts. I'm getting the impression that scripts only get called when there is an event, so that timeouts need to be implemented by scheduling a delayed action? What about making a "tick" event that happens every minute so that virtual devices can maintain their own timing? I don't know if the scripts support persistent variables yet (I'm hoping they do) so that one can keep track of state and time delays between ticks.

Scripts do not have persistant storage, however you can use HS global variables.

[cboles]

Scripts do not have persistant storage, however you can use HS global variables.

Interesting. Perhaps I can make some more complex global variable like a mapped list of objects so that each virtual device (which I presume still can access some unique identifier about itself) can add or access its state variables from this mapped list (or in the worst case, array).

I need to stop guessing and actually look at the coding possibilities... I haven't touched VB in a long time

[cboles]

There are three concepts that may be useful here.
-One is that all devices maintain their own virtual clock, so you can query the time that has elapsed since their last state change.
-Two: Each device has a value associated with it. One use you can put that value to is as a storage location.
-Three: "Events" can be triggered by elapsed or absolute time or by a time condition. You can have a recurring event, for example, every minute, every 10 seconds, or every 13 minutes and 22 seconds, or at 9:47 every Monday, or if a device has been in an 'Off' state for longer than x minutes. You do not have to depend on a physical event to call a script.

Thanks - that should simply things a bit and avoid the need for storage at least for simple timeout scenarios.

[Uncle Michael]

I need to stop guessing and actually look at the coding possibilities... I haven't touched VB in a long time

I bet your options will get a lot clearer quickly once you get back into vb. Keep in mind that HS introduces some scripting calls of its own, so be sure to check the HS help file scripting section.

Among the calls you may find useful, given your questions, are:
hs.SetDeviceValue (to store a value in a HS device, for example), and
hs.DeviceValue (to retrieve a stored value)
I find that using device values to be an easy way to store values for later use or to 'share' among HS events and scripts.

You should also spend some time exploring the wide variety of HS Event triggers. I think you will find that 'event' in the HS world has a very broad meaning.