Poll device from luup? Why isn't SwitchPower1 GetStatus working?

I’m trying to get the light status from a device via upnp from luup since Vera keeps getting out of sync with the actual state of lights when they are switched on/off via group associations from other switches.

However, I can’t figure out how to poll. Based on the SwitchPower1 spec found here: http://www.upnp.org/specs/ha/UPnP-ha-SwitchPower-v1-Service.pdf the service should support GetStatus. However, I tried that in my code and it doesn’t work:

  local error, msg, job, result = luup.call_action("urn:upnp-org:serviceId:SwitchPower1","GetStatus",{ResultStatus=""},device)

The log contains: ZWaveNode::ReceivedMessage serv urn:upnp-org:serviceId:SwitchPower1 action GetStatus unhandled

What am I doing wrong?

-ZMaF

What am I doing wrong?

Probably nothing. Don’t assume that Vera adheres to the UPnP specification. :slight_smile:

According to http://wiki.micasaverde.com/index.php/Luup_UPNP_Files only ‘SetTarget’ is supported.

“urn:micasaverde-com:serviceId:HaDevice1” / “Poll” should do the trick.

Thanks, I will try that.

Is there a list of service/action pairs for the standard services on the wiki?

-ZMaF

http://wiki.micasaverde.com/index.php/Luup_UPNP_Files seems to be THE list (incomplete and partly wrong).

Okay, Poll seems to work. But it is quite slow as it presumably Polls all aspects of a device.

It seems to me that it should be possible to Poll just the switch Status of a switch. Does anyone know how?

-ZMaF

[tt]Poll[/tt] is the only way you’ll get Vera to actually call the device (to refresh the Device-local value in the MiOS Engine)

You can use [tt]luup.variable_get[/tt] on the [tt]Status[/tt] state variable on that device, and that will give you what the MiOS Engine “thinks” it is, just in case the MiOS Browser UI is out of Sync with it’s Engine.

ie. ----- -----

Thanks Guessed,

I understand the caching of the values by Vera. I’m doing the Poll because Vera is ALWAYS out of sync if I use associations to switch my lights. I’m using a timer to force Vera to update those light’s status to the correct one.

I’m surprised that reading the Status from the device isn’t better supported as it seems to be a pretty basic HA feature.

Of course, if Vera were better in sync with the actual switch status, we wouldn’t need it at all.

-ZMaF

I’ve been using variable_get to dig out the status of specific variables rather than polling the device (e.g. luup.variable_get (“urn:micasaverde-com:serviceId:SecuritySensor1”,“Tripped”,64) and it’s been working well for my PIR sensors (3in1) and also offers the advantage of an immediate response.

I take your point that you’re not actually interrogating the device itself but in my experience this hasn’t caused a problem.

The UI sync issue is annoying but as long as you refresh before assuming that it’s a problem with your code, it’s not too big a deal.

Nevertheless, roll on the new release for a whole bunch of reasons!!!

As mentioned before it’s not only the UI that is out of sync, it is also the vera engine. I am running 1.1.1062 and this is the worst version I have had. At the moment I am building a new home automation system myself, I am currently using the vera engine as one of the providers. But I will switch for sure to an open source alternative most probably openzwave.

I had hoped to be able to use the z-wave engine of vera, but it’s so unreliable. My own system logs all states in a database and I intended to use those as input for energy calculations. But more then half of switch states originating from zwave devices are not logged. I have traced it back to the vera engine. I am really dissappointed in vera. And I will phase out as soon as possible.

I’m not at that stage yet but this thread has caused me to look at the polling frequency of my sensors. I now realise that Vera cannot be trusted to do this as some devices often remain un-polled for considerable amounts of time (if at all) leading to intermittent overheat problems.

To be accurate, Vera offers a maximum poll rate and no guarantee that it will poll at that rate but it’s reasonable to assume that it won’t be too far off it especially when there are only a dozen or so devices in the network.

I’ve turned off auto polling and have included some code to do it myself at 60 second intervals and it’s cured the problem. I’ve been blaming the temp sensors when it was Vera all along.

Can you post the command lines to do the manual polling?

luup.call_action(“urn:micasaverde-com:serviceId:HaDevice1”,“Poll”,{},14)

replace 14 with the device id you want to poll

I have a z-wave power strip that is only powered at night (set-up in my backyard and is energized in the evening when landscape lights turn on). Because the switch is “inactive” during the day…Vera reports “cannot detect device”, which makes is unusable even when turned on at night. I get around this by hitting the “poll now” command in the evening and it then becomes usable.

I set-up a scene to manually poll the device at night using the following code (have a day/night virtual switch and pasted the code into the scene).

luup.call_action(“urn:micasaverde-com:serviceId:HaDevice1”, “Poll”, {}, 39)

Rather than this be a “1 time” event, I’d like to poll it every 60 seconds in the evening. Any idea how to add that to the code above?

You would want to use http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#function:_call_delay
or use a scene.