Add push button type

[flatsiedatsie]

I am really missing a built-in push button type.

I was again triggered to create this request while working on a mysensors adapter for the Mozilla Gateway. It has the 'push-button' capability. But I cannot map that to anything in MySensors.

Earlier I noticed that in my sketches I wish I could more clearly have a pushbutton child. For example, in Domoticz a user now has to manually switch a button onto a pushbutton type via the interface. It would be great if this intention could already be built in.

[mfalkvidd]

@flatsiedatsie do I understand correctly that you mean https://iot.mozilla.org/schemas/#PushButton ? Would it make sense to map that to MySensors as S_BINARY with V_TRIPPED?

How are the other Mozilla types mapped to MySensors? (I guess it would make sense to look at S_BINARY with V_STATUS as a comparison.)

[flatsiedatsie]

Would it make sense to map that to MySensors as S_BINARY with V_TRIPPED?

I don't know. Would that work? I'd just like to signal to the controller interface that the button should immediately return to the unpressed state after it is pressed. Right now my nodes 'hack' it by sending a "go back to unpressed state" update after they receive the signal. But in some scenario's that creates unforeseen complexity. And if the return signal is not received, then the controller UX is left in a weird/impossible state.

I'll share a first version of the adapter soon (possibly today), there you can see the initial mapping (still very incomplete, but it works for a few device types now)

[flatsiedatsie]

Getting back to this: do you think most MySensors users would find the behaviour or an S_BINARY with V_TRIPPED being turned into a pushbutton predictable?

If so, then I can make this the behaviour of the WebThings adapter.

[henrikekblad]

I would suggest using S_SCENE_CONTROLLER which usually is a panel with multiple push buttons. The corresponding V_SCENE_ON is triggered when button is pressed. Some scene controllers use V_SCENE_OFF when doing a long press.

[flatsiedatsie]

Hmm, I was just thinking that V_TRIPPED feels more like sensor data than an actuator.

The S_SCENE_CONTROLLER option could work, but feels again a bit like a hack.

Which would again make the point that a dedicated push button type would be really useful?

Just thinking out loud: how about this situation:

S_BINARY <- handles toggle buttons

• V_STATUS. Things like 'long push off' or 'long push on' could just be sent as the number 3 and 4? Double-press off and on could be 5 and 6? Etc.
• V_TRIPPED would be the read-only version. Alternatively, this could be V_STATUS, but with a new V_TYPE called "V_READ_ONLY" to indicate that the controller cannot change it. This could be created for all S_TYPES to help indicate the a UX if the value should be modifiable at the controller side. In this case, if set to 1 it would effectively communicate "I am a binary sensor".
  • V_UNIT<- As with other S_TYPES in MySensors, his would give meta-information about the child. In this case it would indicate if the UX should show "on", "touched", etc, whatever is relevant.
• V_UX / V_META / V_TYPE / V_ICON <- Can be used to optimize the presentation in the UX. For example: "lock", "door", etc.

S_EVENT / S_NOTIFY / S_UNARY / S_MONO / S_PUSH / S_SINGLE <- This handles signals that are not binary, but indicate an event has occurred. Such as push buttons.

• V_STATUS <- The message that the event just occurred. Can be 0 or 1, whichever the user wants. Things like 'long push' could just be sent as the number 3 and 4? Double-press could be 5 and 6? etc.
• V_TRIPPED / V_READ_ONLY <- Same as above, indicates that this cannot be triggered from the controller.
• V_UNIT <- Same as above. Could be "Activate", "Launch", "Send", etc.
• V_UX / V_META / V_TYPE / V_ICON <- Can be used to optimize the presentation in the UX. Could be "push", "smoke_alarm", whatever is agreed upon.

You could create pretty much al singular and binary actuators and sensors with this.

It would also be interesting to decree that all MySensors S_TYPES should henceforth have V_UX / V_META, as well as V_UNIT, to help interfaces better understand how to optimally present the data.

If this was universalized it could be interesting.

Some examples:

A push button: S_EVENT = "Rocket main engine"

• V_STATUS = 1 <- Will send a 1 whenever the button is pressed.
• V_READ_ONLY = 0 <- it can be changed from the controller, so should be shown as some kind of button.
• V_UNIT = "Ignition"
• V_UX = "ask" <- indicates a UX should ask the user "are you sure" first in some capacity.

A singular sensor: S_EVENT = "Passing the equator"

• V_STATUS = 1 <- Will send a 1 at each exact moment the rocket passes the equator.
• V_READ_ONLY = 1
• V_UNIT = "Passing now"
• V_UX = "red" <- should be shown as a virtual big red LED indicator.

A smoke alarm would have two children: S_EVENT = "Smoke detected!"

• V_STATUS = 1
• V_READ_ONLY = 1
• V_UNIT = "No/Yes"
• V_UX = "alarm"

S_BINARY = "Armed and ready"

• V_STATUS = 1
• V_READ_ONLY = 0
• V_UNIT = ""
• V_UX = "checkbox"

Just having some fun: perhaps it would be possible to deal with the issue that S_TYPES will never cover all use cases. Maybe they can be decoupled from this all together? Imagine if there were fewer S_TYPES:

S_MONO S_BINARY S_STRING S_VARIABLE

Then a lot of existing S_TYPES would be described differently:

A wind vane child: S_STRING = "Wind direction"

• V_STATUS = NNW
• V_READ_ONLY = 1
• V_UNIT = ""
• V_UX = "wind"

A bathroom scale: S_VARIABLE = "Your weight"

• V_STATUS = 76
• V_READ_ONLY = 1
• V_UNIT = KG
• V_UX = "needle"

A controller for a thermostat. S_VARIABLE = "Desired temperature"

• V_STATUS = 22
• V_READ_ONLY = 0
• V_UNIT = "Degree Celsius"
• V_UX = "slider"

The actual temperature in the room: S_VARIABLE = "Desired temperature"

• V_STATUS = 21.1
• V_READ_ONLY = 1
• V_UNIT = "Degree Celsius"
• V_UX = "graph" <- If not available, or if V_UX is not sent, then the UX should use the default, which is probably just to show a number.

An air quality sensor: S_VARIABLE = "Fine dust on the balcony"

• V_STATUS = 234
• V_READ_ONLY = 1
• V_UNIT = PPM
• V_UX = "air_quality, graph" <- Children could create a wish list for presentation, with fallback options.

A bathroom scale: S_VARIABLE = "Your weight"

• V_STATUS = 76
• V_READ_ONLY = 1
• V_UNIT = KG
• V_UX = "needle"

A dimmer: S_VARIABLE = "Dimmable lamp"

• V_STATUS = 50
• V_READ_ONLY = 0
• V_UNIT = % <- interfaces should be smart enough to understand that this variable should be limited between 0 and 100.
• V_UX = "slider"

Further musings

Perhaps it could be interesting to add a way of communicating what an entire device is for. This would allow controllers to show related icons, for example.

I_TYPE = "weather_station" or I_TYPE = "doorbell" or I_TYPE = "thermostat" or I_TYPE = "powerplug" or I_TYPE = "power_management" or I_TYPE = "personal_health"

Perhaps this could be aligned with a standard, like the one Mozilla is trying to make.

A lot of these musings have been influenced by working on the MySensors adapter for the Mozilla Webthings Gateway.

[mfalkvidd]

Does anyone know how popular controllers like OpenHab and HomeAssistant handle this type of button? Or don't they support this use case?

[MartinHjelmare]

In Home Assistant, for now, we treat sensors that report V_TRIPPED as binary sensors with state. We don't specifically support push buttons although S_SCENE_CONTROLLER + V_SCENE_ON can be used for that.

I'm planning to fire Home Assistant events for binary sensors, on child update, besides the normal state changes, to allow users to write automations that listen for events and not only state changes. In Home Assistant stateless devices are usually represented as events that fire.

If mysensors would be more specific in reporting if a button has state or is stateless, I think that would allow for a better user experience, where controllers can present the devices and their behavior more close to what they actually are.

[flatsiedatsie]

@MartinHjelmare How could we do that? Do you agree we could explore adding an S_PUSH type?

[MartinHjelmare]

It would probably involve adding a new S type and one to many V types for the different push events. Probably at least two different push events, click and hold (long press) should be represented.

I haven't given this much thought yet.