[APP][Pro&Cloud] Shelly

[Igy]

Yes. Name it gate and if you want to use voice, say turn on gate.

[Phuturist]

@Phuturist

@Sebastian_Lotz

the action events out_on an out_off are changes from 1101 value 0 → 1 (out_on) or 1101 value 1 → 0 (out_off). Same with 1201 on the second channel of shelly2/2.5. I Think you use 1101/1201 already for updating the states of the device in your shelly app (since 3.0.x it updates right away because of the coap messages)

So instead of using the action event out_on and out_off you can use the action flow card of the device itself an use “switched on” or “switched off”

Same thing with btn_on and btn_off: these are changes from 2101 value 0 → 1 (btn_on) or 2101 value 1 → 0 (btn_off).
You allready added a capability “State of Input X”. This capabilty is available in the action flow card of the device itself as well (State of Input 2), so you don’t need the btn_on and btn_off event anymore.

Ok, this is good stuff. I’ll switch to using CoAP for action events in a future release. This is another major change and I might wait until Homey firmware 5.x becomes stable (which could take months seeying the development cycle of Athom).

@Sebastian_Lotz are you willing to test release 3.0.5 which I just pushed to the master branch on Github? It includes action events over CoAP for the Shelly1 devices. When the Shelly1 driver is loaded it will remove all callback URLs from the connected Shelly1 devices and listen for action events over CoAP. I would like to see this tested before I migrate other devices with supported action events over CoAP.

There are actually a couple of action events that do not seem to be supported like the ‘roller_open’, ‘roller_close’ and ‘roller_stop’ events for the Shelly 2(.5) roller shutter. I’ll stick to the REST API for these unsupported events unless someone can tell me if they are also supported (and with what shortcode).

[Martijn_Hoogenbosch]

Why not just push it to the test branch?

[Phuturist]

Because this is easier for me.

[Martijn_Hoogenbosch]

fair enough

[Sebastian_Lotz]

Hi,

I tested the new function. So far, it does not work correctly.

When I push a button of a shelly1 device, the app logs a “Device does not support reported capability inputEventCounter0 with value xxx” error…

Can you add a little bit more logging that I can see, how the app interpreted the CoAP-Message?

Good thing is, that everytime you push a button, you get a log line. That meens that the shelly sends the input events and the app is receiving something…

log:
2020-11-20 19:17:36 [log] [ShellyApp] Discovered device with ID A4CF12F3EDCB and type SHSW-1
2020-11-20 19:19:01 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 191
2020-11-20 19:19:05 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 192
2020-11-20 19:19:09 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 193
2020-11-20 19:19:10 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 194
2020-11-20 19:19:11 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 195
2020-11-20 19:19:14 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 196
2020-11-20 19:19:15 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 197
2020-11-20 19:19:21 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 198
2020-11-20 19:19:26 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 199
2020-11-20 19:19:31 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 200
2020-11-20 19:19:32 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 201
2020-11-20 19:19:34 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 202
2020-11-20 19:19:40 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 203
2020-11-20 19:19:45 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 204
2020-11-20 19:19:46 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 205
2020-11-20 19:19:51 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 206
2020-11-20 19:19:53 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 207
2020-11-20 19:22:07 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 208
2020-11-20 19:22:14 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 209
2020-11-20 19:22:17 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 210
2020-11-20 19:22:19 [log] [ManagerDrivers] [shelly1] [3] Device does not support reported capability inputEventCounter0 with value 211

[Sebastian_Lotz]

@Phuturist

There are actually a couple of action events that do not seem to be supported like the ‘roller_open’, ‘roller_close’ and ‘roller_stop’ events for the Shelly 2(.5) roller shutter. I’ll stick to the REST API for these unsupported events unless someone can tell me if they are also supported (and with what shortcode).

I am pretty shure that you can get roller_open, roller_close and roller_stop via COAP as well…
I will look into it with wireshark…

btw. with coap you get input events for the 2.5 in roller shutter as well. Shelly implementet those not via action event (I don’t know why they didn’t)

Sebastian

[Phuturist]

@Sebastian_Lotz

Can you add a little bit more logging that I can see, how the app interpreted the CoAP-Message?

I pushed an update to GitHub that should give more logging for the Shelly 1. Give it a go.

@Sebastian_Lotz

I am pretty shure that you can get roller_open, roller_close and roller_stop via COAP as well…
I will look into it with wireshark…

btw. with coap you get input events for the 2.5 in roller shutter as well. Shelly implementet those not via action event (I don’t know why they didn’t)

Ok, please supply me with information and I’ll add it once we have the CoAP action events working.

[Sebastian_Lotz]

roller_open —> 1102 changes from something (e.g. “stop”) to “open”
roller_close —> 1102 changes from something (e.g. “open”) to “stop”
roller_stop —> 1102 changes from something (e.g. “open”) to “close”

{“G”:[[0,9103,0],[0,1102,“open”],[0,1103,60],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4102,99.75],[0,4104,1861],[0,6103,“normal”],[0,3104,64.04],[0,6101,0],[0,9101,“roller”]]}

{“G”:[[0,9103,0],[0,1102,“stop”],[0,1103,60],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4102,0.00],[0,4104,1861],[0,6103,“normal”],[0,3104,64.04],[0,6101,0],[0,9101,“roller”]]}

{“G”:[[0,9103,0],[0,1102,“close”],[0,1103,13],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4102,101.76],[0,4104,1892],[0,6103,“normal”],[0,3104,63.90],[0,6101,0],[0,9101,“roller”]]}

[Sebastian_Lotz]

tried new version.

Seems that only the first input event is being processed. Only after changing the event from “S” to “L” it works again…

So it seems that you don’t process the InputEvent every time when the inputEventCounter counts up…

See the log:
✓ Connection restored, some logs might be missing
2020-11-20 20:31:30 [log] [ManagerDrivers] [shelly1] [3] registered relay0 with value false
2020-11-20 20:31:30 [log] [ManagerDrivers] [shelly1] [3] registered inputEvent0 with value S
2020-11-20 20:31:30 [log] [ManagerDrivers] [shelly1] [3] matched inputEvent0 with value S in switch case
2020-11-20 20:31:30 [log] [ManagerDrivers] [shelly1] [3] S translated to shortpush, going to trigger flow card now
2020-11-20 20:31:30 [log] [ManagerDrivers] [shelly1] [3] registered inputEventCounter0 with value 214
2020-11-20 20:31:41 [log] [ManagerDrivers] [shelly1] [3] registered inputEventCounter0 with value 216
2020-11-20 20:31:43 [log] [ManagerDrivers] [shelly1] [3] registered input0 with value 1
2020-11-20 20:31:43 [log] [ManagerDrivers] [shelly1] [3] registered relay0 with value true
2020-11-20 20:31:43 [log] [ManagerDrivers] [shelly1] [3] registered input0 with value 0
2020-11-20 20:31:43 [log] [ManagerDrivers] [shelly1] [3] registered inputEventCounter0 with value 217
2020-11-20 20:31:45 [log] [ManagerDrivers] [shelly1] [3] registered relay0 with value false
2020-11-20 20:31:45 [log] [ManagerDrivers] [shelly1] [3] registered inputEventCounter0 with value 218
2020-11-20 20:31:47 [log] [ManagerDrivers] [shelly1] [3] registered input0 with value 1
2020-11-20 20:31:47 [log] [ManagerDrivers] [shelly1] [3] registered relay0 with value true
2020-11-20 20:31:47 [log] [ManagerDrivers] [shelly1] [3] registered input0 with value 0
2020-11-20 20:31:47 [log] [ManagerDrivers] [shelly1] [3] registered inputEventCounter0 with value 219
2020-11-20 20:31:49 [log] [ManagerDrivers] [shelly1] [3] registered input0 with value 1
2020-11-20 20:31:50 [log] [ManagerDrivers] [shelly1] [3] registered inputEvent0 with value L
2020-11-20 20:31:50 [log] [ManagerDrivers] [shelly1] [3] matched inputEvent0 with value L in switch case
2020-11-20 20:31:50 [log] [ManagerDrivers] [shelly1] [3] L translated to longpush, going to trigger flow card now
2020-11-20 20:31:50 [log] [ManagerDrivers] [shelly1] [3] registered inputEventCounter0 with value 220
2020-11-20 20:32:00 [log] [ManagerDrivers] [shelly1] [3] registered inputEventCounter0 with value 221
2020-11-20 20:32:00 [log] [ManagerDrivers] [shelly1] [3] registered inputEventCounter0 with value 222
2020-11-20 20:32:02 [log] [ManagerDrivers] [shelly1] [3] registered input0 with value 0
2020-11-20 20:32:04 [log] [ManagerDrivers] [shelly1] [3] registered input0 with value 1
2020-11-20 20:32:07 [log] [ManagerDrivers] [shelly1] [3] registered input0 with value 0
2020-11-20 20:32:07 [log] [ManagerDrivers] [shelly1] [3] registered inputEventCounter0 with value 223
2020-11-20 20:32:08 [log] [ManagerDrivers] [shelly1] [3] registered input0 with value 1
2020-11-20 20:32:08 [log] [ManagerDrivers] [shelly1] [3] registered relay0 with value false
2020-11-20 20:32:08 [log] [ManagerDrivers] [shelly1] [3] registered input0 with value 0
2020-11-20 20:32:08 [log] [ManagerDrivers] [shelly1] [3] registered inputEvent0 with value S
2020-11-20 20:32:08 [log] [ManagerDrivers] [shelly1] [3] matched inputEvent0 with value S in switch case
2020-11-20 20:32:08 [log] [ManagerDrivers] [shelly1] [3] S translated to shortpush, going to trigger flow card now
2020-11-20 20:32:08 [log] [ManagerDrivers] [shelly1] [3] registered inputEventCounter0 with value 224
2020-11-20 20:32:09 [log] [ManagerDrivers] [shelly1] [3] registered input0 with value 1
2020-11-20 20:32:10 [log] [ManagerDrivers] [shelly1] [3] registered inputEvent0 with value L
2020-11-20 20:32:10 [log] [ManagerDrivers] [shelly1] [3] matched inputEvent0 with value L in switch case
2020-11-20 20:32:10 [log] [ManagerDrivers] [shelly1] [3] L translated to longpush, going to trigger flow card now
2020-11-20 20:32:10 [log] [ManagerDrivers] [shelly1] [3] registered inputEventCounter0 with value 225
2020-11-20 20:32:11 [log] [ManagerDrivers] [shelly1] [3] registered input0 with value 0

[Sebastian_Lotz]

btw. if it works, the flow reacts much faster than before…

I checked all the action events in the shelly1:

BUTTON SWITCHED ON URL → You don’t need that action event, because you got a capability for that “STATE OF SW TERMINAL”, you just need an action flow card for that capability…

BUTTON SWITCHED OFF URL → You don’t need that action event, because you got a capability for that “STATE OF SW TERMINAL”, you just need an action flow card for that capability…

BUTTON LONG PRESSED URL → Will work, if you process the inputEvent everytime the inputEventCounter counts up.

BUTTON SHORT PRESSED URL → Will work, if you process the inputEvent everytime the inputEventCounter counts up.

OUTPUT SWITCHED ON URL → You don’t need that action event, because you got the “standard” action flow card “Device is on” for that and changes of the device are processed right away because the CoAP-Messages update that.

OUTPUT SWITCHED OFF URL → You don’t need that action event, because you got the “standard” action flow card “Device is off” for that and changes of the device are processed right away because the CoAP-Messages update that.

---

About the shelly 2.5 in roller shutter mode:

@Sebastian_Lotz

roller_open —> 1102 changes from something (e.g. “stop”) to “open”
roller_close —> 1102 changes from something (e.g. “open”) to “stop”
roller_stop —> 1102 changes from something (e.g. “open”) to “close”

{“G”:[[0,9103,0],[0,1102,“open”],[0,1103,60],[0,2101,0],[0,2102,“”],[0,2103,0],[0,2201,0],[0,2202,“”],[0,2203,0],[0,4102,99.75],[0,4104,1861],[0,6103,“normal”],[0,3104,64.04],[0,6101,0],[0,9101,“roller”]]}

{“G”:[[0,9103,0],[0,1102,“stop”],[0,1103,60],[0,2101,0],[0,2102,“”],[0,2103,0],[0,2201,0],[0,2202,“”],[0,2203,0],[0,4102,0.00],[0,4104,1861],[0,6103,“normal”],[0,3104,64.04],[0,6101,0],[0,9101,“roller”]]}

{“G”:[[0,9103,0],[0,1102,“close”],[0,1103,13],[0,2101,0],[0,2102,“”],[0,2103,0],[0,2201,0],[0,2202,“”],[0,2203,0],[0,4102,101.76],[0,4104,1892],[0,6103,“normal”],[0,3104,63.90],[0,6101,0],[0,9101,“roller”]]}

There are actually a couple of action events that do not seem to be supported like the ‘roller_open’, ‘roller_close’ and ‘roller_stop’ events for the Shelly 2(.5) roller shutter. I’ll stick to the REST API for these unsupported events unless someone can tell me if they are also supported (and with what shortcode).

Btw. I don’t think you need that action events anymore, as you got the action flow card “The Status has changed” with “up” (=roller_open), “inactive” (=roller_stop) and “down” (=roller_close).

[Phuturist]

@Sebastian_Lotz

Seems that only the first input event is being processed. Only after changing the event from “S” to “L” it works again…

@Sebastian_Lotz

BUTTON LONG PRESSED URL → Will work, if you process the inputEvent everytime the inputEventCounter counts up.
BUTTON SHORT PRESSED URL → Will work, if you process the inputEvent everytime the inputEventCounter counts up.

I’m afraid I’m out of luck then. I’m using a nodejs library (GitHub - alexryd/node-shellies: Handles communication with Shelly devices) for the CoAP communication and I’m processing every CoAP event that is being processed by the library. So if not all events are coming through this either means they are not send by the Shelly device (can be checked with wireshark) or the nodejs library is not registering all of them. I can image only actual changes from S to L or L to S are registered. Perhaps there is an issue/bug in the library where it only process the event when the event differs from the previous event. Could you check this?

@Sebastian_Lotz

Btw. I don’t think you need that action events anymore, as you got the action flow card “The Status has changed” with “up” (=roller_open), “inactive” (=roller_stop) and “down” (=roller_close).

Correct, I’ll remove those events in a future version.

[Sebastian_Lotz]

@Phuturist

I’m afraid I’m out of luck then. I’m using a nodejs library (GitHub - alexryd/node-shellies: Handles communication with Shelly devices) for the CoAP communication and I’m processing every CoAP event that is being processed by the library. So if not all events are coming through this either means they are not send by the Shelly device (can be checked with wireshark) or the nodejs library is not registering all of them. I can image only actual changes from S to L or L to S are registered. Perhaps there is an issue/bug in the library where it only process the event when the event differs from the previous event. Could you check this?

I checked it. It seems only to report changed values. That’s why shelly implemented the inputEventCounter:

Input event
This is a new property, that together with “Input event counter” shall be used to evaluate events such as shortpush/longpush/etc. It provides a short string, denoting the last detected input event (“S” = shortpush, “L” = longpush, …). “” (empty string), means that no event has occurred yet, or that the last detected event is invalid (i.e. not among the recognized patterns). Please note that range of detected events is device specific. Not stored in non-volatile memory.

Input event counter
Incremented each time a new input event is detected (the exact type of the event doesn’t matter). The counter is not stored in non-volatile memory.

Right now such events are for example shortpush/longpush of buttons – devices will send a property of type “EV” to denote the exact event type (“S” = shortpush, “L” = longpush), and a property of type “EVC” that will increment it’s value when a new event occurs (e.g. to be able to know that two consecutive longpushes are actually two separate events).
Please see “Input event” and “Input event counter” in the property list below for additional information.
In the future, it’s possible that a type “EVV” (Event validity) will be added too, to denote how long an occurred event should be considered “active” (e.g. for motion, vibration, etc.)

So you just need to store the (last) Input event.

If a new Input Event counter comes in, then fire the action flow card with the stored Input event.
Try something like this (remember, I am not a programmer, but I think you geht the idea) :

   case 'inputEvent0':
      this.log('matched '+ capability +' with value '+ value + ' in switch case');
      this.actionEvent = this.util.getActionEventDescription(value);
	  this.log(value +' translated to '+ this.actionEvent);
      break;
    case 'inputEventCounter0':
	this.log('inputEventCounter fired, last captured actionEvent' + this.actionEvent);
      this.homey.flow.getTriggerCard('triggerCallbacks').trigger({"id": this.getData().id, "device": this.getName(), "action": this.actionEvent}, {"id": this.getData().id, "device": this.getName(), "action": this.actionEvent});
      break;

Seb

[Phuturist]

@Sebastian_Lotz

If a new Input Event counter comes in, then fire the action flow card with the stored Input event.
Try something like this (remember, I am not a programmer, but I think you geht the idea)

That makes two of us, I’m not a programmer as well. But I do get the idea. Just wondering how this will play out in timing. I can image the eventCounter case is sometimes processed before the value of the inputEvent has been processed and thus triggering a flow for the wrong event. That could be fixed by adding a small delay before triggering the card but I havent added this yet. Could you check the updates on Github and do a little testing if it now always triggers and triggers with the right event.

[Sebastian_Lotz]

Hi,

now it works. I tried it 50-60 times, it allways chooses the right event, even multiple times…
in the CoAP-Message the actionEvent is allways before the actionEventCounter. It seems that they are processed in the right sequence…

P.S. If I look at your code, for me you are a programmer

Sebastian

[Phuturist]

Thanx for testing, I’ll add it to all drivers soon.

[Phuturist]

@Sebastian_Lotz

Hi,

now it works. I tried it 50-60 times, it allways chooses the right event, even multiple times…
in the CoAP-Message the actionEvent is allways before the actionEventCounter. It seems that they are processed in the right sequence…

Ok, I have updated all drivers to use CoAP for the action events. This is a major change that will also remove the HTTP callbacks if it detects a Shelly is still sending these events. Would you be willing to test drive this before I push it to the test channel in the app store? The master branch on Github has been updated.

[Sebastian_Lotz]

Will do. Looked at the changes, seems to be OK.
Installed it and betatest it with the family tomorrow…

couple of things:

1. Right now it seems that triggering a flow is somehow slower again. I will look into that with wireshark tomorrow as well.
2. Maybe wait a little bit longer as of tomorrow there should be an firmware update available to 1.9.0 for the shellys. I have 1.9.0RC3 on my shellys (because of problems with wifi stability) and I will update the firmware to the final version tomorrow, too. So far I got no glitches or problems…
3. Could you make a official capability for the input events as well as the “Input state”. That way the last input event would be shown next to other stuff like power, temperatur and the “State of Input”?
4. Could you change the shown value of the “State of Input” into “On/Off” or “switched on” / “switched off” instead of “Yes/No”
5. For the capability “State of Input” maybe some people need an action flow card, because of the removale of the action triggers (btn_on, btn_off). I don’t use that kind of action event…

Tell you tomorrow in the evening, how it went…

Sebastian

[Sebastian_Lotz]

I found one glitch: The new event names are missing in the shelly action flow card for the dimmers (shortpush_1 and so on). Only the old ones are there.
You have to choose the device again to see the new events…
Can you get the event items if you choose the event or open the flow card and not after you choose the device?

For other devices, it adds the new event items and don‘t remove the old ones. Only after you re-choose the device, the old ones are gone and only the new ones are there.

Another thing: There seems to be a bug in the shelly firmware for the dimmers. The CoAP message for the longpush is sent only after you release the Button. For the other shellys it is sent right away after a longpush is recognized as a longpush. I will open a ticket with Shelly about that.
That might be the cause, that I wrote yesterday, that there are some delays. But I will look into that again this evening…

Sebastian

[Phuturist]

@Sebastian_Lotz

Could you make a official capability for the input events as well as the “Input state”. That way the last input event would be shown next to other stuff like power, temperatur and the “State of Input”?

It’s of course possible but would this really be of any value?

@Sebastian_Lotz

Could you change the shown value of the “State of Input” into “On/Off” or “switched on” / “switched off” instead of “Yes/No”

According to the documentation this is not possbile for default capabilities (I’m using alarm_generic for the inputs) but I’ll ask around.

@Sebastian_Lotz

For the capability “State of Input” maybe some people need an action flow card, because of the removale of the action triggers (btn_on, btn_off). I don’t use that kind of action event…

Because I use the default alarm_generic capability these flow cards are generated automatically. That’s exactly why I’m using default capabilities as much as possible and am hesitant to create or switch custom capabilities. Custom capabilities makes managing the app more time consuming.

@Sebastian_Lotz

I found one glitch: The new event names are missing in the shelly action flow card for the dimmers (shortpush_1 and so on). Only the old ones are there.
You have to choose the device again to see the new events…
Can you get the event items if you choose the event or open the flow card and not after you choose the device?

The autocomplete dropdown retrieves its values when clicked. You are seeying old values probably because the values have not been refreshed yet and it’s showing previously selected values. This is the way these input fields work and part of Homey core and I have no control over it… It wont be much of a problem for the majority of users when they switch to version 3.x because by then they should have the correct values and they need to update these triggercards anyway.

@Sebastian_Lotz

For other devices, it adds the new event items and don‘t remove the old ones. Only after you re-choose the device, the old ones are gone and only the new ones are there.

See comment above.

@Sebastian_Lotz

Another thing: There seems to be a bug in the shelly firmware for the dimmers. The CoAP message for the longpush is sent only after you release the Button. For the other shellys it is sent right away after a longpush is recognized as a longpush. I will open a ticket with Shelly about that.
That might be the cause, that I wrote yesterday, that there are some delays. But I will look into that again this evening…

Ok, let’s hope CoAP does not turn out to be slower than the REST API for action events and all my efforts would be in vain.