[APP][Pro&Cloud] Shelly

Yes, I did. But there was no green message, that the change was saved. Nevermind, I retried it cause I wanted to save a video, but I cannot reproduce it. If it happens again, I will save a video…

Done :slight_smile: Thanks for locking into that.

Thanks for looking into that. I didn’t read that out of the documentation…

What I don’t understand is the following sentence in the link you gave me:
Input events are only detected when btn_type is configured as momentary , momentary_on_release or detached .

If a button is “detached”, it doesn’t drive an output. So I thought the CoAP-Message for that Input-Event sould be fired. As well as the action event, that is configured.

I will ask shelly about that and if I get a positive response the author of the library that you are using (Alexander Rydén) …

I have uploaded verion 3.0.3 to the test channel in the app store. Most noticable changes sinze 3.0.2 are:

  • Support for Shelly Uni
  • Added a mechanism that will update the device IP address if it detects a paired Shelly that has been added under a different IP address than it’s currently available in the network. Useful for people that have not assigned static IP addresses to their devices.
  • Made the trigger cards for the optional temperature sensors of the Shelly 1 and Shelly 2 more generic to support the Shelly Uni as well. This will require you to update any flows using these trigger cards.
  • Improved the action event card allowing user to select all devices and/or all actions to trigger a flow

If you want to use or test this version see this post for more details. You can also find the entire changelog of the 3.x versions of the app in that post.

1 Like

Thanks for your Quick add Shelly UNI :wink:

It’s only for homey 5.0x users right?
Not availible for 4.2.0v

Thanks for your great work

Right, only homey V5

1 Like

Hi,

i’m testing v3 for a few days now and it performens great. A lot more stable. Thank you for that!
Yesterday I bought 2 shelly plug s and linked them to homey. I notice that the values ​​for temperature and energy are not being updated. Only when linking is a value passed and then no longer. The values ​​will be updated in the shelly cloud app. Is this a known issue. I couldn’t find it on the forum

No it’s not. I’ll look into it soon.

1 Like

Are you planning add support for DETACHED mode for inputs? As detached input, button will not change output, only trigger action, this is great for people like me, who wants to use output for garage gate, and input as doorbell (device is there, so why not use it inputs?)

Device: Relay 2.5

What would this look like in terms of changes within the Shelly app for Homey? With version 3.x the input states are added as generic alarms allowing you to use them as triggers and conditions but this seems unrelated to your request. The actions events are already triggered independent of which mode the device is configured so they will also trigger in detached mode. What else would you like to see?

Ummm, in detached mode, how can i get trigger? Do not see it in flows, on/off and some others,but no activate/click event or somethink like that… Maybe I miss somethink (happends to me sometimes). Guess i will need to wait for v3 of homey :slight_smile:

I’m running my dimmer2 in detached mode. Input singals and output isn’t controlled by that, I can do anything with it.

@Phuturist I do however have with this particular light a issue. Sometimes it is on but homey thinks it’s off. If I open the Shelly app, it is on. The same time it is off in homey. The strange thing is when I turn it off in the Shelly app and turn it on, it is on in homey too.

Any thoughts on which situations this could hapen?

My scenario I want to do… Set inputs to detached mode.
Input 1 = doorbell, activate will trigger flow in homey
Input 2 = no action for now
Output 1 = ON/OFF (with AutoOff after 2 sec) - trigger by homey only
Output 2 = ON/OFF (with autoOff after 10 sec) - trigger by homey only
And Question is, is this possible with Shelly app right now, as I do not found flow WHEN DEVICE IS PRESSED, so I guess i miss somethink obvious, or need functionality that is not possible in Homey V4

Read the instructions from the first post. There is a generic triggercard available under the app (not under device) to catch any action event. From the 3.x version of the app this triggercard has been improved but this requires Homey firmware 5.x. Read some posts up if you want to test.

See if you can get it to work with the generic triggercard as mentioned above. Your Input and Output terminology is confusing in relation to the Shelly API. If you can not get it to work have a look at the REST API as described here to see whats possible: Welcome to Shelly Technical Documentation | Shelly Technical Documentation

Looks to me that the CoAP message which is used to update the device state in Homey is either not received or processed by Homey. In the first case it’s out of my hands as that is part of the functionality of the Shelly device and should be fixed there. In the second case I would have to see why it isnt processed within my app correctly. I do not use this app myself anymore so I cant really look into it. But I can create a debug version that spits out the on/off coap messages to the command line. You should run it and wait until it happens again and then check if the message was received or not. Let me know if you want a swing at this.

Yes please, doesn’t happen all the time, so don’t know if i’m able to find it. But yes, let’s check. Is there a possibility to filter the debug on only one device?

If you can post the output of /status and /settings of the device you want to look at I can do that.

Yes, I can do that, I’ll send it through a PM

Hi,

first at all: Thanks for your work and the 3.0.3 Version!

  1. I tried out the new action card, an if I choose “With Any Device”, I get an emty list for the “Select Action”, and there is no way to save the action card (the chechmark up right is greyed out). Maybe a bug? … or did I do someting wrong?

  2. I tested the new function to auto-change the IP address and it worked for me! Great! There is much less risk of using DHCP now.

  3. I got in contact with shelly about the COAP-Messages as a substitute for the “action events”, and they confirmed to me, that there is a cit/s-Message, if somebody pushes a button. Here is what they say:

the cit/d packet contains a description of the properties communicated via Coap. What you need to look for is the cit/s packet, which is the status. The device sends it whenever there is a change in its state - for example, when you press a button you will get a new cit/s packet to inform you about this.

I tested it, and they are right:

With every action event there is a cit/s message with all the Information needed.
The cit/s-Messages are coming as well if there is no action event configured!

The first /cit/s : → Shelly Dimmer → 1st input button pressed shortly
{“G”:[
[0,9103,0],
[0,1101,0],
[0,5101,30],
[0,2101,0], → Input state of Channel “0” is “0” = off
[0,2102,“S”], → Last Input Event was “S” = Shortpush
[0,2103,15], → Input Counter = 15, new event, since the last number of pevious cit/s message was “14”
[0,2201,0], → Input state of Channel “1” is “0” = off
[0,2202,“S”], → Last Input Event was “S” = Shortpush
[0,2203,3], → Input Counter still 3 → no new event on the 2nd button
[0,4101,0.00],
[0,4103,3169],
[0,6102,0],
[0,6104,0],
[0,3104,52.69],
[0,3105,126.85],
[0,6101,0],
[0,9101,“white”]
]}

the 2nd /cit/s message: → Shelly Dimmer → 2nd input button pressed shortly

{“G”:[
[0,9103,0],
[0,1101,0],
[0,5101,30],
[0,2101,0], → Input state of Channel “0” is “0” = off
[0,2102,“S”], → Last Input Event was “S” = Shortpush
[0,2103,15], → Input Counter still 15 → no new event on the first button
[0,2201,0], → Input state of Channel “1” is “0” = off
[0,2202,“S”], → Last Input Event was “S” = Shortpush
[0,2203,4], → Input Counter = 4 → new input event, since the last number of pevious cit/s message was “3”
[0,4101,0.00],
[0,4103,3169],
[0,6102,0],
[0,6104,0],
[0,3104,52.69],
[0,3105,126.85],
[0,6101,0],
[0,9101,“white”]
]}

Here is another example with “Btn_on”-Event (another device in another room):

1st button hold down:
{“G”:[
[0,9103,0],
[0,1101,1],
[0,5101,10],
[0,2101,1], → 1st Button is on (btn_on)
[0,2102,“L”], → Longpush Event
[0,2103,40], → New count 40 = new event
[0,2201,0],
[0,2202,“S”],
[0,2203,17],
[…]
]}
button released:
{“G”:[
[0,9103,0],
[0,1101,1],
[0,5101,79],
[0,2101,0], ----> 1st Button released (btn1_off)
[0,2102,“L”],
[0,2103,40], —> Still 40, no new long button event, but 1st Button is released now…
[0,2201,0],
[0,2202,“S”],
[0,2203,17], → Still 17, no new event for dhe 2nd Button
[…]
]}

So with coap there is probably no need to set/remove/process the action events anymore, the app could process the COAP-Messages instead directly and get the same data to fire the flow cards.

The probably biggest advantage is that the multiple action event HTTP messages no longer need to be processed. If multible are fired, the processing is slowed down from my experience.
With COAP you get the bnt_on, btn_longpress, out_on event with one COAP-Message…

I hope you understand what i wrote in english, not a native speaker :slight_smile:

Best regards

Sebastian

I can not reproduce this. This should only happen when there are no devices paired that support action events. So there is probably a bug. Could you run the app from the command line and see if it shows any errors there?

The input event (with attribute 2102) only supports S and L for short and longpush so it’s not a replacement for all possible values of the action urls. You should ask Allterco to add all other possible events. Once that has been implemented I can switch to using CoAP without losing functionality.

@Sebastian_Lotz I was looking at some CoAP documentation from Shelly. In this document it was stated that there are other input events. Unfortunately the documentation is not clear on all available events. This is what it says:

The possible values as stated in the documentation are [“S/L/SS/SSS/SL/LS”,””]. but I’m not sure if these values are actually all available. Could you confirm this. And what about the btn_on, btn_off, out_on and out_off events that can be added as callbacks. Are these available or even relevant?

I looked into this but based on a code review I’m not seeying anything funny. Do you know how to run an app from the command line using homey app run command? I could create a debug version that might give more information on what is going on.

Hi,

about:

I can not reproduce this. This should only happen when there are no devices paired that support action events. So there is probably a bug. Could you run the app from the command line and see if it shows any errors there?

─────────────── Logging stdout & stderr ───────────────
2020-10-29 23:35:43 [log] [ShellyApp] Initializing Shelly App …
2020-10-29 23:36:26 [log] [ShellyApp] Discovered device with ID A4CF12F42A64 and type SHSW-1
2020-10-29 23:36:26 [log] [ShellyApp] Discovered device with ID 500291F0AB84 and type SHSW-1
2020-10-29 23:36:28 [log] [ShellyApp] Discovered device with ID 68C63AFB1AD3 and type SHSW-25
2020-10-29 23:36:30 [log] [ShellyApp] Discovered device with ID 68C63AFAE9B7 and type SHSW-PM
2020-10-29 23:36:31 [log] [ShellyApp] Discovered device with ID A4CF12F4226D and type SHSW-1
2020-10-29 23:36:31 [log] [ShellyApp] Discovered device with ID BCDDC277C186 and type SHSW-1
2020-10-29 23:36:32 [log] [ShellyApp] Discovered device with ID 68C63AF928B9 and type SHSW-25
2020-10-29 23:36:32 [log] [ShellyApp] Discovered device with ID A4CF12F488AA and type SHSW-1
2020-10-29 23:36:33 [log] [ShellyApp] Discovered device with ID 68C63AFB19DD and type SHSW-25
2020-10-29 23:36:33 [log] [ShellyApp] Discovered device with ID 68C63AFAE936 and type SHSW-PM
2020-10-29 23:36:33 [log] [ShellyApp] Discovered device with ID 68C63AFB0F22 and type SHSW-25
2020-10-29 23:36:34 [log] [ShellyApp] Discovered device with ID D8BFC019ED6C and type SHDM-2
2020-10-29 23:36:34 [log] [ShellyApp] Discovered device with ID 68C63AFAF4FF and type SHSW-PM
2020-10-29 23:36:34 [log] [ShellyApp] Discovered device with ID 68C63AFAEF93 and type SHSW-PM
2020-10-29 23:36:34 [log] [ShellyApp] Discovered device with ID 68C63AF92B3F and type SHSW-25
2020-10-29 23:36:34 [log] [ShellyApp] Discovered device with ID 68C63AFAEEC8 and type SHSW-PM
2020-10-29 23:36:34 [log] [ShellyApp] Discovered device with ID 68C63AF926FB and type SHSW-25
2020-10-29 23:36:35 [log] [ShellyApp] Discovered device with ID 68C63AF96FF2 and type SHSW-25
2020-10-29 23:36:35 [log] [ShellyApp] Discovered device with ID D8BFC019ED84 and type SHDM-2
2020-10-29 23:36:35 [log] [ShellyApp] Discovered device with ID 68C63AF92E59 and type SHSW-25
2020-10-29 23:36:35 [log] [ShellyApp] Discovered device with ID 68C63AF95EFD and type SHSW-25
2020-10-29 23:36:35 [log] [ShellyApp] Discovered device with ID D8BFC019ED3E and type SHDM-2
2020-10-29 23:36:35 [log] [ShellyApp] Discovered device with ID A4CF12F421E7 and type SHSW-1
2020-10-29 23:36:37 [log] [ShellyApp] Discovered device with ID BCDDC277C7D8 and type SHSW-1
2020-10-29 23:36:37 [log] [ShellyApp] Discovered device with ID 500291F012B8 and type SHSW-1
2020-10-29 23:36:44 [log] [ShellyApp] Discovered device with ID D8BFC019E590 and type SHDM-2
2020-10-29 23:36:44 [log] [ShellyApp] Discovered device with ID 68C63AF96FCA and type SHSW-25
2020-10-29 23:36:44 [log] [ShellyApp] Discovered device with ID 68C63AFB1089 and type SHSW-25
2020-10-29 23:36:44 [log] [ManagerDrivers] [shelly25-rollershutter] [6] Device does not support reported capability rollerStopReason with value normal
2020-10-29 23:36:45 [log] [ShellyApp] Discovered device with ID 68C63AFAF5E9 and type SHSW-PM
2020-10-29 23:36:45 [log] [ShellyApp] Discovered device with ID 68C63AF92F91 and type SHSW-25
2020-10-29 23:36:45 [log] [ShellyApp] Discovered device with ID D17CFF and type SHDM-1
2020-10-29 23:36:45 [log] [ShellyApp] Error: invalid_device
at Shelly25Driver.getDevice (/opt/homey-client/node_modules/homey-apps-sdk-v3/lib/Driver.js:240:11)
at Shelly25. (/app.js:243:92)
at Shelly25.emit (/node_modules/eventemitter3/index.js:184:35)
at Shelly25.set [as deviceTemperature] (/node_modules/shellies/lib/devices/base.js:116:16)
at Shelly25._applyUpdate (/node_modules/shellies/lib/devices/base.js:181:20)
at Shelly25._applyUpdate (/node_modules/shellies/lib/devices/shelly-2.js:61:11)
at Shelly25.update (/node_modules/shellies/lib/devices/base.js:167:10)
at Shellies._statusUpdateHandler (/node_modules/shellies/index.js:41:14)
at StatusUpdatesListener.emit (/node_modules/eventemitter3/index.js:181:35)
at CoAPServer.handler (/node_modules/shellies/lib/status-updates-listener.js:25:18)
2020-10-29 23:36:45 [log] [ShellyApp] Discovered device with ID 68C63AFB1C62 and type SHSW-25
2020-10-29 23:36:45 [log] [ManagerDrivers] [shelly25-rollershutter] [8] Device does not support reported capability rollerStopReason with value normal
2020-10-29 23:36:45 [log] [ShellyApp] Discovered device with ID D178EE and type SHDM-1
2020-10-29 23:36:45 [log] [ShellyApp] Discovered device with ID DBEF87 and type SHPLG-S
2020-10-29 23:36:45 [log] [ShellyApp] Discovered device with ID 68C63AF9447A and type SHSW-25
2020-10-29 23:36:46 [log] [ManagerDrivers] [shelly25-rollershutter] [12] Device does not support reported capability rollerStopReason with value normal
2020-10-29 23:36:46 [log] [ManagerDrivers] [shelly25-rollershutter] [12] Device does not support reported capability deviceTemperature with value 63.08
2020-10-29 23:36:46 [log] [ShellyApp] Discovered device with ID 68C63AFAEC2B and type SHSW-PM
2020-10-29 23:36:46 [log] [ShellyApp] Discovered device with ID 68C63AFAF46E and type SHSW-PM
2020-10-29 23:36:46 [log] [ShellyApp] Discovered device with ID 68C63AFB1AA2 and type SHSW-25
2020-10-29 23:36:46 [log] [ManagerDrivers] [shelly25-rollershutter] [0] Device does not support reported capability rollerStopReason with value normal
2020-10-29 23:36:46 [log] [ManagerDrivers] [shelly25-rollershutter] [0] Device does not support reported capability deviceTemperature with value 64.74
2020-10-29 23:36:46 [log] [ShellyApp] Discovered device with ID 68C63AF92C3E and type SHSW-25
2020-10-29 23:36:46 [log] [ManagerDrivers] [shelly25-rollershutter] [2] Device does not support reported capability rollerStopReason with value normal
2020-10-29 23:36:46 [log] [ShellyApp] Discovered device with ID 68C63AF916ED and type SHSW-25
2020-10-29 23:36:47 [log] [ManagerDrivers] [shelly25-rollershutter] [10] Device does not support reported capability rollerStopReason with value normal
2020-10-29 23:36:47 [log] [ManagerDrivers] [shelly25-rollershutter] [10] Device does not support reported capability deviceTemperature with value 64.04
2020-10-29 23:36:47 [log] [ShellyApp] Discovered device with ID D8BFC019D892 and type SHDM-2
2020-10-29 23:36:47 [log] [ManagerDrivers] [shelly25-rollershutter] [1] Device does not support reported capability rollerStopReason with value normal
2020-10-29 23:36:47 [log] [ManagerDrivers] [shelly25-rollershutter] [1] Device does not support reported capability deviceTemperature with value 61.89
2020-10-29 23:36:51 [log] [ShellyApp] Discovered device with ID A4CF12F3EF47 and type SHSW-1
2020-10-29 23:36:53 [log] [ShellyApp] Discovered device with ID 68C63AF96F39 and type SHSW-25
2020-10-29 23:37:00 [log] [ManagerDrivers] [shelly25-rollershutter] [11] Device does not support reported capability rollerStopReason with value normal
2020-10-29 23:37:00 [log] [ManagerDrivers] [shelly25-rollershutter] [8] Device does not support reported capability deviceTemperature with value 63.49
2020-10-29 23:37:01 [log] [ManagerDrivers] [shelly25-rollershutter] [7] Device does not support reported capability rollerStopReason with value normal
2020-10-29 23:37:02 [log] [ManagerDrivers] [shelly25-rollershutter] [2] Device does not support reported capability deviceTemperature with value 64.74
2020-10-29 23:37:02 [log] [ManagerDrivers] [shelly25-rollershutter] [14] Device does not support reported capability rollerStopReason with value normal
───────────────────────────────────────────────────────
✓ Uninstalling cloud.shelly
✓ Homey App cloud.shelly successfully uninstalled

Here is the log.
If I select the “With any device” an then “Select Action” there is nothing in the log. But maybe the other exception could produce the error in the flow card?

Sebastian