Zoneplayer does not switch between ONLINE and OFFLINE about openhab-addons HOT 14 CLOSED

mmh.... how to achieve that with UPNP? Will check if that can be done through a time-out on the GENA subscription, otherwise we have to add some polling mechanism that checks on one or the other Sonos variable.

from openhab-addons.

Hm, I thought you are always doing a polling anyhow? And on invokeAction() you could probably check if it works or not.
Actually, I haven't seen GENA working yet - onValueReceived is always only called through the updateMediaInfo() method, but never as a GENA callback. Is there anything I need to do to activate it?

from openhab-addons.

No, nothing should be activated for GENA. The subscriptions are registered when the handler is initialized (onSubscription()), but that being said, I am investigating an issue (related to the volume bug) whereby for some reason the GENA subscriptions are working in the UPNPIoImpl, but the resulting value sets are not always handed over to the handler. Beware, not all devices implement all subscriptions we ask for - you are always testing again a Play:1 right? That one does not implement the Media Rendered embedded device and thus not the RenderingControl UPNP service. It is that service that is returning the volume information, so I need to check how that is done on a Play:1. (the 1.x binding was developed before the launch of the Play:1, Sub and Playbar)

from openhab-addons.

Kai, just fixed a GENA bug, PR is in ESH repo.

from openhab-addons.

Yes, I am always testing on a Play:1 with the latest firmware - i.e. without a bridge.

from openhab-addons.

Kai, after reflecting, this is already implemented, but we depend on jupnp to be signalled about devices leaving the network. In fact, ZonePlayer is a DiscoveryListener, so whenever a device is removed, then the UPNPDiscoveryService's remoteDeviceRemoved() callback is called, which calls thingRemoved(), and subsequently informs the DiscoveryListeners through a call to thingRemoved(). That method is already implemented by ZonePlayer, and it sets the status to OFFLINE. Maybe the jupnp Registry is not fast/reactive enough to pick up the change, and/or maybe the device needs to be unplugged long enough
That being said, do you see a use case whereby a Sonos player is disconnected and moved around very often? in most installation I presume they will be very static

What we could do (holds true for any type of Thing) is inserting a check on ThingStatus in handleCommand()

from openhab-addons.

we depend on jupnp to be signalled about devices leaving the network

Well, if a device is unplugged, it doesn't have the chance to send any notifications. And afaik, upnp then works with a TTL, which can be many minutes, before it assumes the device having left the network.

I agree that it is not a common use case, but it should still be covered. Especially when sending a command it should notice if it cannot reach the device and update the thing status accordingly.

What exactly was the polling job good for? If this will remain, why not add a check into this?

from openhab-addons.

We could use the status flag on the les of the device for this purpose. It is not difficult but will have the case with all upnp classes. Or we could investigate this ttl in jupnp?

Sent from my iPhone

On 15 Nov 2014, at 23:55, Kai Kreuzer [email protected] wrote:

we depend on jupnp to be signalled about devices leaving the network

Well, if a device is unplugged, it doesn't have the chance to send any notifications. And afaik, upnp then works with a TTL, which can be many minutes, before it assumes the device having left the network.

I agree that it is not a common use case, but it should still be covered. Especially when sending a command it should notice if it cannot reach the device and update the thing status accordingly.

What exactly was the polling job good for? If this will remain, why not add a check into this?

—
Reply to this email directly or view it on GitHub.

from openhab-addons.

doing changes about ttl is imho not an option as this is handled according to upnp specification.
What are the technical possibilities to check if a upnp device is reachable? Only sending actions to it? Isn't the polling job requesting data from the device and should be able to notice if it does not succeed?

from openhab-addons.

Well, via invokeAction it will always succees since it is uncoupled from the binding, so I think we have to poll for a variable, like the status of the led, and see if any response comes back (e.g. empty result set)

On 16 Nov 2014, at 10:10, Kai Kreuzer [email protected] wrote:

doing changes about ttl is imho not an option as this is handled according to upnp specification.
What are the technical possibilities to check if a upnp device is reachable? Only sending actions to it? Isn't the polling job requesting data from the device and should be able to notice if it does not succeed?

—
Reply to this email directly or view it on GitHub #42 (comment).

from openhab-addons.

Kai, I see other options to solve this:
a. do a Discovery at a given interval, with interval TBD in function of requirements. We will be notified automatically if the Thing is removed from the registry, no?
b. Reduce the timeout and refresh interval on the GENA subscriptions, so that we can capture a vanished device through the failure to re-subscrive to a GENA subscription

Following the UPNP specs, the Sonos Player should indicate a kind of interval by which is sends NOTIFY messages that it still alive. I don't know that value yet, but if a NOTIFY is not received by jupnp in the given interval, then the deviceRemoved() etc is called.

from openhab-addons.

a) No - discovery services can currently only add, but not remove devices.
b) Might be an option. Do you see any risk associated with this?

It is weird that UPnP does not offer anything to check, whether the device is available at all...

from openhab-addons.

on b) I have no idea. the only thing I could think of is that an event could be missed when refreshing the subscription, but to confirm that we have to look at the jupnp code I guess.

As far as I have read through the specs, the only have the NOTIFY principle whereby a device has to broadcast that it is still offering the service.

from openhab-addons.

Sonos binding is moving to ESH, so I am closing this issue.

from openhab-addons.