My site sensor for OpenWeatherMap has not been acting as expected. I have it tied to my house mode and its set to only be ‘armed’ when the house mode is ‘home’, otherwise its ‘disarmed’. Ive noticed that when the house mode changes back to ‘home’ my sensor reads ‘Disarmed - Query Skipped’ even though its showing as ‘armed’ in the UI (see screenshot). I left it like this for about two days in hope the next time it was disarmed/armed by the house modes it would work, but according to the device the last query was June 7. I could set the sensor to query regardless if its disarmed or armed but I don’t see the need to check the weather when everyones asleep, because my current logic only uses it for turning my water fountain on or off.
What’s the value of the “Armed” state variable on the sensor (assuming you haven’t changed it already)?
Armed state variable is ‘1’
And how are you arming and disarming it when the house mode changes?
natively through ‘My Modes’ in the UI
When you reported the value of “armed” up above, how did you arrive at that?
I didn’t do it, it was just like that when the house mode changed from night->home this morning.
That’s not what I mean. What was the process by which you determined the value of “Armed” to be 1?
Ah, under ‘Variables’ of the sensor, then checked the ‘Armed’ value
Using ALTUI’s interface, or Veras?
Vera’s UI but just checked ALTUI and its the same for Armed
OK. In the background, I did a quick test. It looks like, when Vera changes house modes, in setting the arming state of security sensor devices, rather than calling the SetArmed UPnP function, it manipulates the related state variable directly. SiteSensor needs SetArmed to be called in order to launch a new “thread” to restart the query process. Because Luup is simply manipulating the variable directly, SiteSensor doesn’t “see” that change–it remains asleep in idle state and does not wake up.
This is an error on Vera’s part. It is yet another rotten implementation decision, not the first I’ve run into this week. If you use other UPnP devices and the overall model as an example, you do not make devices do things by changing state variables. You make devices do things by invoking actions, and the action updates the state variables with intent and status. For example, if you want to turn a light on, you can change the Target state variable until you’re blue in the face, but it’s not going to turn the light on or off. If you invoke the SetTarget action in the SwitchPower1 service, however, it sets the Target variable to reflect your desired state of the light, communicates with the device, and then ultimately the updates that come from the device reflecting the change in status are reflected in the Status variable on the device.
The SecuritySensor1 service has a SetArmed action. The “My Modes” monkey-motion isn’t using it. Fail.
I may add a workaround to SiteSensor for this, but I may not. For the moment, don’t use “query only when armed” if using “My Modes” (and I would avoid using “My Modes” in general; IMO, it’s been nothing but trouble since it appeared). To kick your sensor awake, just disarm it and then re-arm it.
Ah thanks for the in-depth explanation! Maybe we could add this in the docs? A quick reactor condition will fix this issue for me
Edit:
Is it possible to remove the sensor from the ‘My Modes’ section? I will test this again but if I set it to ‘armed’ in any mode it still gives me the same issue. Again I will test this again later today to double check but I do recall this happening.
Okay so I just tested, if I leave the sensor to be armed in all the house modes and I use reactor to disarm when the mode is NOT set to home I still run into the same issue.
My logic is simple:
House mode home is true - Set the sensor to armed
House mode home is fall - Set the sensor to disarmed
The issue is that when the sensor disarms and the house mode is set back to home, the same thing happens where the sensor is not armed properly. Even though I have a RS condition to arm it correctly, I guess the house mode governs and it sets it incorrectly before the reactor activity is able to send the command. To combat this in my true condition I’ve set the sensor to be set to disarmed initially then set it back to armed so that its armed correctly (see screenshot).
The problem is not at disarming, the problem is arming.
When the sensor is disarmed, the timer process (which cannot be cancelled in Luup) is still running in the background. When the timer expires, the handler in SiteSensor then sees that the sensor is disarmed and does nothing, and most importantly, does not reschedule another timer, it just lets itself go dead.
When the sensor is armed using the action (i.e. the correct way), the action handler for SetArmed in SiteSensor sets the state variable (as it should), and then schedules a new timer process for one second out to run a “bootstrap” query immediately. Subsequent queries will then use the configured interval (the timer gets rescheduled on the interval by each query when armed).
If you are allowing “My Modes” to arm the sensor, it is still arming it the wrong way and the timer task is not being scheduled as a result. You can get away with disarming the sensor via My Modes, but arming the sensor via My Modes will not work.
…and I’ve now done a stable branch workaround for the My Modes issue, so if you want to just try that out instead of doing machinations with Reactor, let me know and I’ll give you install instructions (if you need them).
That did the trick thanks again Patrick!
1 Like