[APP][Pro&Cloud] Shelly

No this is not fine and is the reason the devices are not updated after initial restart. I’m trying to figure out why you get this message. In the debug version I added some code that should show an object of the devices added to Homey. Do you see this when you start running the app from the command line. It could also show [] if it’s indeed empty (what the log seems to indicate).

No live filtering is available. Copy and paste to a texteditor for this.

This is a new feature as requested here: Feature request: Allow users to use the input state on Shelly 1 SW input · Issue #85 · jghaanstra/cloud.shelly · GitHub . Looks like I still need to update the initial state for the 1PM on start-up though.

All related to the device updates not coming through.

I have pushed a new debug release to Github with a possible fix for devices not updating and that will spit out some different logging. Could you re-download and let me know what you see on the console. Let it run at least for a couple of minutes please.

1 Like

Seems to work again; both issues.

2020-10-10 12:08:15 [log] [ShellyApp] Discovered device with ID E5AF28 and type SHSW-PM
2020-10-10 12:08:15 [log] [ShellyApp] Discovered device with ID E0980695B698 and type SHDM-2
2020-10-10 12:08:15 [log] [ShellyApp] Discovered device with ID 00D478 and type SHSW-PM
2020-10-10 12:08:15 [log] [ShellyApp] Discovered device with ID 68C63AFB6C2F and type SHSW-PM
2020-10-10 12:08:15 [log] [ShellyApp] Discovered device with ID B92F94 and type SHSW-PM
2020-10-10 12:08:15 [log] [ShellyApp] Discovered device with ID B907AF and type SHSW-PM

Pretty sure it didn’t do this before. Did get some CPU warnings, but that’s fine I guess.

The power updates again. I do have the feeling it’s a bit slower than before, turning off the light, it takes ~13 sec to update the power value to 0W. Sometimes a bit faster but not that much. Don’t know for sure though, could be just in my head.

The state of SW terminal is now set to ‘No’, don’t know what it means, but there at least is something :wink: -> i’ve read the issue on github, its more clear, don’t have to do anything with it except when having a reed switch, didn’t even know about what it was.

Thanks!

I’m getting the following in the log:

 {
    id: 'shellydimmer2-E0980695B698',
    name: '💡💡 Hal boven',
    ip: '192.168.1.10',
    icon: '/drivers/shellydimmer/assets/icon.svg',
    driver: 'shellydimmer',
    type: 'SHDM-2',
    main_device: 'none',
    actions: [
      'btn1_on',
      'btn1_off',
      'btn2_on',
      'btn2_off',
      'out_on',
      'out_off',
      'btn1_shortpush',
      'btn1_longpush',
      'btn2_shortpush',
      'btn2_longpush'
    ]
  }
]
2020-10-10 12:21:49 [log] [ManagerDrivers] [shellydimmer] [0] Device does not support reported capability inputEventCounter0 with value 444

Probably shouldn’t happen, right?

Good to hear, that pinpoints the issue. I’m not satisfied with the solution but at least I know what is going on. I’ll see if I can improve this further.

That is weird, the devices I tested with where updated pretty much instantly when there is a change. The coap protocol that is now in place in my app just listens for updates from the Shelly devices instead of having to poll their status. Usually a Shelly device should send an update instantly.

I have pushed a new debug version to Github. Could you run this again. It should display a log of changes actually published to devices. When swithing your dimmer from the webinferface you should see the switch state and power usage change. I’m curious how long it takes for the update comes in.

https://github.com/jghaanstra/cloud.shelly/tree/debug

That works as intended, it’s just some capability available in the coap protocol that I have not implemented as I see no value in it (this partical message is saying 144 action events have be registered for your Shelly Dimmer).

Seems a lot better. If I open the webpage, it now changes the power at the same speed as on the webpage of the device, which is probably as fast as possible I’d recon. Sometimes even faster. Turning off is instantly. Don’t know if you have changed anything, but it seems faster (i’m getting the impression you haven’t changed anything in regards to this).

Nope, did not change anything there. Perhaps it was just a sluggish Homey that was causing the delay earlier. I have pushed the changes to the app store as test version. Please continue to test community. See this post for more details: [APP] Shelly

1 Like

Confirming that produced energy is in kWh now, but there is rounding issue

@Phuturist isn’t there a possibility to have a 2x press option for the Dimmer2? I’ve got long and short press, but no 2x press. I used to think there was.

Reason I want this is because i’ve got a bunch of Dimmer2 modules from Fibaro, and 2x push is set to 100% brightness, long press is dim to lowest value. It is really hard to explain why it works on most lights, but some it is different.

If it’s not doable, i’ve got to look at another possibility, just don’t know yet :wink:

The Shelly Dimmer does not support a double push callback.

I was afraid of that, that sux! I’ll see what i can do, thanks

Not sure if it would work but in theory you can create some flows that would register two single presses within x seconds as a double press.

mehh… not a really nice solution. If I think of it, it would look like something, single press -> set var to 1, second flow, single press and var = 1 then 100%? Not that nice if you ask me, do you have a different way?

No, as mentioned it’s not supported.

I meant for flows. If it’s not supported by api then yes, i understand it’s not possible. I opened a technical ticket @ shelly, I highly doubt it’ll work, but still. Tnx anyways


They redirected me to push for a feature request. Obviously I did fill the form, but I don’t expect this to come any time soon, or even at all. Since I don’t expect I’m the only one in the world looking for this feature.

Hallo Jelger,

great new release!
I switched to Homey 5.0.0_RCx now as well as my other devices are no supported.

I like the switch from polling to Coap, that one fixed the strange behaivior that some devices are “gone” (not reachable) for the shelly app and you could still access the webpage for the device. Great!

I also like the new “Action event”-Flow card, where you can select the Device an the action which you want to catch.

I have found one bug/strange behaivior that I didn’t find mentioned so far:
When I i trigger a callback from the device, the shelly-app is sometime reacting right away and sometims 1-5 Seconds later. That was not happening before.

Could it be, that there are sometimes a couple of events at the same time, that need to be processed via the app (for example: btn_on, btn_shortpush, out_on). Could it be a needed solution that you can choose the Callbacks you want the callback URL’s set on the shelly?
I only use the shelly-app for callbacks, I didn’t set any more on my own.

On last thing:
I used the old “Action event” flow card for the situation, that the house is shutting itself down, when noone is around. If there ist still a person in it, he/she could press a button on any shelly-switch for the next 60 seconds to reverse it. With the new “Action event” flow card, this is not possible anymore, as it seems. Can you add the old “Action event” flow card to the version 3.0.x of you app, too? The one, where any event is captured and you needed better logic to select the events you want to process.
E.g. name the old one "Action event (global), and the other one “Action event (per device)”.
If you have the two possibilitys, it would be really great!

Tell me, if I can do anything to narrow the delays of the callback-URL’s down…

Tanks for you really great work, Sebastian

Btw. Is it possible to exchange the URL-Callback processing with your new Coap-Code, as well? Probably depends whether the shelly sends Coap-Messanges when a button is switched…

You are right about some actions triggering multiple requests that need to be processed. It would indeed be better to disable the callbacks which you do not use. Although I considered adding this logic into my app it is quite cumbersome for something that is easily managed from the Shelly webinterface and probably does not change that often. I had already added some information about this in the installation instructions telling the user to disable unused callbacks. If this is actually the cause of the delay you are experiencing I do not know, might as well be a (temporary) sluggish Homey). I have not changed anything in the way this is handled in my app so it’s strange that you now see this behaviour if you did not change anything in your setup

If you know how to do a command line install I can create a debug version of the app that spits out information about when an event is received and handled by my app. This will at least show if the delay is due to processing time in my app or because of a sluggish Shelly, Homey or network in general.

No I wont. I probably can add an option to the new card that triggers on any received event when selected. Feel free to submit a feature request on Github. [EDIT: nevermind: I already added it, will be available with the next update]

No, this information is not available under the CoAP protocol.

Hi,

Can you add please Shelly UNI?

IP/Status:

{“wifi_sta”:{“connected”:true,“ssid”:“IoT Unser Haus”,“ip”:“192.168.1.134”,“rssi”:-56},“cloud”:{“enabled”:true,“connected”:true},“mqtt”:{“connected”:false},“time”:“20:28”,“unixtime”:1603398516,“serial”:3,“has_update”:false,“mac”:“483FDA82C408”,“cfg_changed_cnt”:1,“actions_stats”:{“skipped”:0},“relays”:[{“ison”:false,“has_timer”:false,“timer_started”:0,“timer_duration”:0,“timer_remaining”:0,“source”:“input”},{“ison”:false,“has_timer”:false,“timer_started”:0,“timer_duration”:0,“timer_remaining”:0,“source”:“input”}],“inputs”:[{“input”:1},{“input”:0}],“adcs”:[{“voltage”:3.09}],“ext_sensors”:{},“ext_temperature”:{},“ext_humidity”:{},“update”:{“status”:“idle”,“has_update”:false,“new_version”:“20200812-092537/v1.8.0@8acf41b0”,“old_version”:“20200812-092537/v1.8.0@8acf41b0”},“ram_total”:50976,“ram_free”:37996,“fs_size”:233681,“fs_free”:160138,“uptime”:4546}

And

Up/Settings:

{“device”:{“type”:“SHUNI-1”,“mac”:“483FDA82C408”,“hostname”:“shellyuni-483FDA82C408”,“num_outputs”:2},“wifi_ap”:{“enabled”:false,“ssid”:“shellyuni-483FDA82C408”,“key”:""},“wifi_sta”:{“enabled”:true,“ssid”:“IoT Unser Haus”,“ipv4_method”:“dhcp”,“ip”:null,“gw”:null,“mask”:null,“dns”:null},“wifi_sta1”:{“enabled”:false,“ssid”:null,“ipv4_method”:“dhcp”,“ip”:null,“gw”:null,“mask”:null,“dns”:null},“mqtt”: {“enable”:false,“server”:“192.168.33.3:1883”,“user”:"",“id”:“shellyuni-483FDA82C408”,“reconnect_timeout_max”:60.000000,“reconnect_timeout_min”:2.000000,“clean_session”:true,“keep_alive”:60,“max_qos”:0,“retain”:false,“update_period”:30},“coiot”: {“update_period”:15},“sntp”:{“server”:“time.google.com”,“enabled”:true},“login”:{“enabled”:false,“unprotected”:false,“username”:“admin”},“pin_code”:“m})eW>”,“name”:null,“fw”:“20200812-092537/v1.8.0@8acf41b0”,“factory_reset_from_switch”:true,“discoverable”:false,“build_info”:{“build_id”:“20200812-092537/v1.8.0@8acf41b0”,“build_timestamp”:“2020-08-12T09:25:37Z”,“build_version”:“1.0”},“cloud”:{“enabled”:true,“connected”:true},“timezone”:“Europe/Berlin”,“lat”:52.322899,“lng”:9.819090,“tzautodetect”:true,“tz_utc_offset”:7200,“tz_dst”:false,“tz_dst_auto”:true,“time”:“20:32”,“unixtime”:1603398723,“actions”:{“active”:false,“names”:[“out_on_url”,“out_off_url”,“btn_on_url”,“btn_off_url”,“longpush_url”,“shortpush_url”,“btn_on_url”,“btn_off_url”,“longpush_url”,“shortpush_url”]},“hwinfo”:{“hw_revision”:“prod-202008”, “batch_id”:0},“mode”:“relay”,“longpush_time”:800,“relays”:[{“name”:null,“ison”:false,“has_timer”:false,“default_state”:“off”,“btn_type”:“toggle”,“btn_reverse”:0,“auto_on”:0.00,“auto_off”:0.00,“schedule”:false,“schedule_rules”:},{“name”:null,“ison”:false,“has_timer”:false,“default_state”:“off”,“btn_type”:“toggle”,“btn_reverse”:0,“auto_on”:0.00,“auto_off”:0.00,“schedule”:false,“schedule_rules”:}],“adcs”:[{“range”:12}],“ext_sensors”:{}}

Great work buddy!!

Thanks

Hi,

I think I found a bug:
If you want to change the IP-address of a shelly device, you can change it and save the new parameter. But if you come back into the dialog, the “old” IP address is still there. It looks like it doesn’t save it.

Btw. : If a device goes offline and is unavailable, could it be a good idea to check the mDNS-Messages (that you use for finding the Shelly devices for pairing) for an new IP address?
If you found a new one, replace the existing address with the new adress. This way the shelly would be found again and you can use DHCP for the shellys which ist much less configuration, if you have a lot of devices.
I don’t know if this is possible and would be a good feature request to add to github…

Sebastian

P.S. I found out what causes the delays of the action events after I updated to 3.0.0:
First, I re-added the actions events via your device configuration page, so I had more events fireing than before. If you have a push-button, it will fire three events (btn_on, btn_off, btn_shortpush) and homey takes it time to process those (usally 100-300ms per event).
Second I got an firmware update at around the same time for the unify AP’s. After that I had to chance some options in the wifi-options cause there were some delays contacting the shelly devices. I found that out via wireshark looking for the action event and the response after homey processed the aktion flow card. Btw.: that time is usually around 100-300ms, but sometimes even 500ms per event.
So all good with the new version.

I understand.
I found some information in the version 2 (firmware >= 1.8.0)about that here:

that looked for me like that information is available in the coap messages …

“T”:type (mandatory)

  • <type> will always be 1 to 3 characters, only capital letters.

For now the following types are declared:

<type> Description
[…]
“EV” Event
“EVC” Event counter

[…]
“EV” (Event) and “EVC” (Event counter) are newly introduced types to be able to communicate the occurrence of events. 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 its value when a new event occurs (e.g. to be able to know that two consecutive longpushes are actually two separate events).

I can not reproduce this. Save the IP just fine when changing here. Are you sure you saved the changes?

Perhaps, but the whole mDNS implementation is not part of my app but of Homey core. Adding this would mean I’d have to add this from scratch. I’d rather look into the IP address being available in the CoAP messages. I can match it there with an added device under a different IP it would be a much better solution. Feel free to submit it to Github.

So it seems, it’s not availabe in the nodejs library I’m using but I’ll see if I can work together with the developer of that library to have it added in time.

I looked into this but these attributes are not for the action events but for input events. See for instance the details about this on the Shelly 1PM here under the header inputs attributes