Yes. Name it gate and if you want to use voice, say turn on gate.
@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).
Why not just push it to the test branch?
Because this is easier for me.
fair enough
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
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
I pushed an update to GitHub that should give more logging for the Shelly 1. Give it a go.
Ok, please supply me with information and I’ll add it once we have the CoAP action events working.
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”]]}
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
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:
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).
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?
Correct, I’ll remove those events in a future version.
I checked it. It seems only to report changed values. That’s why shelly implemented the inputEventCounter:
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
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.
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
Thanx for testing, I’ll add it to all drivers soon.
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.
Will do. Looked at the changes, seems to be OK.
Installed it and betatest it with the family tomorrow…
couple of things:
- Right now it seems that triggering a flow is somehow slower again. I will look into that with wireshark tomorrow as well.
- 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…
- 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”?
- Could you change the shown value of the “State of Input” into “On/Off” or “switched on” / “switched off” instead of “Yes/No”
- 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
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
It’s of course possible but would this really be of any value?
According to the documentation this is not possbile for default capabilities (I’m using alarm_generic for the inputs) but I’ll ask around.
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.
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.
See comment above.
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.
