local polling sensor for Connector online state

[DanielDecker]

I think a sensor which can forward the online state of Connectors would be useful. This way an online status indicator or a fallback action can be configured in case a Connector goes offline. The idea is to check every X seconds (configured polling interval) if the named Connector(s) is / are online. If offline for a certain time, send a command to a local actuator (e.g. on / off).

To make such a sensor possible I would add a new function to the connection class for requesting information about the connection (e.g. kind=local/remote, state=online/offline).

@rkoshak: what do you think of this proposal?

[rkoshak]

I could have sworn I've replied to this before. Did you file an issue perhaps or maybe clicking the green button didn't work and I didn't notice.

Well, better late than never.

The idea seems reasonable. I can definitely see it being useful to fall back to a kind of autonomous mode when the connectors are offline.

I think I originally had in mind something more simple but never got around to it. I was just going to add a method to Connector that anything that uses a Connector that cares (would work for Actuators too) could call to find out of a Connector is online and take specific action as necessary.

[DanielDecker]

Thanks for your replay.

Meanwhile the idea has evolved a bit. Instead of a polling sensor, I think a "dummy connector" that polls a named connector for the online state is the better solution. This way an actuator that uses this dummy connector in its config can:

• be set a specific value when the named connector goes offline
• restore the last value after the connection is established again

While writing this comment I thought, why not edit the 'connection(ABC)' base class in utils to include the 'offline action' handling, so that the other connectors can inherit it.

[rkoshak]

I'm still wondering if this approach is sufficient.

I'm thinking of two cases:

1. when a connector goes offline/online do something
2. when a new sensor reading needs to be reported

If we are going to make the connector status available I think we need to handle both cases. And that means I think we need both approaches. We need something (to trigger an actuator when it goes offline/online) and we need something that a sensor can query to discover the status prior to publishing.

I agree, adding the offline action handling in the base class is the better way to go.

[DanielDecker]

I'm thinking of two cases:

1. when a connector goes offline/online do something

I understand case one for actuators: the actuator should do something. Do you mean it more general?

2. when a new sensor reading needs to be reported

I don't understand case two. If a sensor wants to report a reading but the connector is offline what options are left except wait for the reconnect? Of course, the connector should report the last sensor state after reconnection. This should be optional since this is only useful for some sensors.

[rkoshak]

I understand case one for actuators: the actuator should do something. Do you mean it more general?

I try to make things as general as possible (more use cases get captured this way). But since only actuators can respond to the event that's as general as it gets; the actuator should do something.

If a sensor wants to report a reading but the connector is offline what options are left except wait for the reconnect?

Other options are to throw the sensor reading away or to queue up sensor readings and send them as a group or a burst on reconnect.

Because some sensors are in a polling loop, they can't really wait for the connector to come back without throwing away the sensor readings. For some sensors, it might be more important that all readings are captured and reported even when not connected. Polling sensors cannot handle that and have to throw away sensor readings when the connection is down.

And for the sensor to know that it needs to save up the readings it needs to know if the connection is online.

[DanielDecker]

Other options are to throw the sensor reading away or to queue up sensor readings and send them as a group or a burst on reconnect.

I hadn't thought about queuing up sensor readings. I can see this beeing useful when using the BtleSensor, for example.

I'll try implement this in the connector base class.

[DanielDecker]

Issue fixed with #129