[APP][Pro&Cloud] Shelly

Yes, fork the Github repo for the 1.25.6 version, update app.json on line 277 and change it to "value": "^shelly1?l-|pm-". The install the app using the command line with homey app install.

Would it also work to manually add actions to the buttons which homey then captures and start a flow?

Hello @Phuturist,

trying right nowā€¦

I found two things so far:

  1. If you reboot a shelly, an action flow card ist fired, because there is an new (resetted) eventCounter.
    You need to check if it is counting up - and if not - reset it to the new value (possibly 0) and donā€™t fire an event.

Something like this (initialise with ā€˜-1ā€™, as the first eventCounter will be ā€˜0ā€™):

        case 'inputEventCounter0':
      if value > this.getStoreValue('actionEventCounter') then
          this.setStoreValue('actionEventCounter', 'value')
          this.homey.flow.getTriggerCard('triggerCallbacks').trigger({"id": this.getData().id, "device": this.getName(), "action": this.getStoreValue('actionEvent')}, {"id": this.getData().id, "device": this.getName(), "action": this.getStoreValue('actionEvent')});
      else
           this.setStoreValue('actionEventCounter', 'value')
      break;

maybe there is a better alternativeā€¦

  1. If you delete the action events with ā€˜nullā€™ an reboot the device, the action events are still there. The shelly doesnā€™t seem to accept the delete. They a shown in the on the html frontend as well. If you delete it there, it does seem to work, but if you reboot, they are still there again.
    Could you check that with your shellys, maybe they react differentlyā€¦

So I reseted the device that there are only coap messages (and mqtt) if I press a button.
Result with 1.93RC3:
After I resetted the device (and the action events are gone in the shelly) it was better.
The mqtt-message was sent e.g. 20:33:10.78 and the coap message was sent 20:33:11.16 so 380 ms later.

Tried several timesā€¦
2nd try: 430 ms later
3rd try: 280 ms later
4rd try: 290 ms later

so much better.

But it seems that we really need to get rid of the action events, as they slow down the coapā€¦

Seb

Itā€™s kind of weird it sends an CoAP message for the eventCounter after a reboot. Iā€™ll ask the guys at Allterco Robotics why this is happens. Having to catch that in my app would be annoying.

Weird, Iā€™m pretty sure I tested it when I implemented it like that. But perhaps I didnt check after a reboot. Watching soccer right now but will check tomorrow and see what needs to be done to permanently delete the action events. Itā€™s good to hear this (and perhaps 1.9.3 RC2 ) helps with the performance.

No, it is probably not. After the reboot, a new coap message is send. In the coap message is every value in it, so even the InputEventCounter. But it is ā€œ0ā€, because, nothing happend so farā€¦ But it is there. The coap messages allways have the same layout, just different data. But the coap lib, that you are using, detects a change of a value an sents that new value to your routine.
So it is not, that the eventCounter = 0 that is the problem, but the ā€œchangeā€ that is detected.
Right now you are acting on every change, so that you get a InputEventCounter-change delivered you fire an action flow card. But in the special event of a reboot there is a change as well (from e.g. 24 to 0), but you can check, that the new value is smaler. Normaly Shelly counts upā€¦

Weird, Iā€™m pretty sure I tested it when I implemented it like that. But perhaps I didnt check after a reboot. Watching soccer right now but will check tomorrow and see what needs to be done to permanently delete the action events. Itā€™s good to hear this (and perhaps 1.9.3 RC2 ) helps with the performance.

I think you did and it worked in the past. I think that because you added an reset of the device, because without it, it didnā€™t work. I can remember that. But not working anymore (at least for my Shellyā€™s)

Seb

Ok, makes sense. It would be easier to drop the eventCounter message when the value of the counter is 0. That avoids having to save data under the device and is easier to implement. Iā€™ll look into that soon.

Iā€™ll check it again.

I hope to have solved both these issues in version 3.0.6 which is currently only available on Github. Feel free to try it out. I might push it to the test channel at a later time.

I upgraded to homey 5.0 latest rc and installed the test version of the Shelly app.

As explained above I also see the delay on some of the shelly devices. Tested on one of them to upgrade to the latest rc firmware of Shelly and this is working faster. Shall test further with the other shelly devices.

One thing I noticed is that with the new Shelly 1L in button detached mode Homey doesnā€™t receive an action when pressed.

You could try the version currently available on Github if you know how to do a command line install with homey app install. That should properly remove the HTTP action event URLā€™s that are causing some delay according to @Sebastian_Lotz.

Odd, sounds like a bug in the firmware for the Shelly 1L though. I dont have this device so I cant test it.

Yes, itā€™s confirmed by the Allterco Robotics that HTTP request are handled before CoAP and thus can cause a delay.

Yes HTTP actions has highest priority ESp8266 cannot handle multiple request at time for that reason we not recommend costumer to set more than 2 actions per event. But if TCP responce is slow this will delay whole proces even they are 1 or 2. If they use Homey they donā€™t need local HTTP requests i think.

I have factory resetted one of the shelly devices and the speed is somewhat as before. Let me find out how to install software via SSH (or if you have the whole command by hand please share it). Will the app be still visible in Homey gui and will it auto-update to the latest version when available?

For the Shelly 1L can I debug this for you somehow? If yes, let me know what to do and Iā€™m glad to help.

Got the same response from shelly as well:

Hi, yes, the http actions have highest priority - to increase the coap response time please limit the number of http actions. Also, please update to the latest firmware which should be available in a couple of days, this should help especially with the Shelly 2.5.

Will try the new versionā€¦

Instruction can be found here: [HOW TO] CLI install method. It will be visible but wonā€™t auto update. But you can just install the test version again from the app store (which wonā€™t auto update as well as far as I know).

If you know how to use wireshark you could monitor the traffic and see if the device send the CoAP messages. If you learned how to run apps from the command line I can also create a debug version of the app to see if Homey receive any messages. Just let me know.

Now removing the action commands works!
I tried it with a shelly dimmer that still had the action URLs listet in the web frontent. After pushing a button the events were gone an the action flow card was fired much faster.

Looking into other devices now.
I found some strange behaivior with longpushes an a shelly1 that I will look into.

ā€¦and a reboot doesnā€™t fire an action flow card anymore! This seems to be fixed.

Sebastian

btw. I changed the homey IP-Adress some weeks ago.
These action urls (and maybe others) are not removed - I expexted that!
But such stuff could still make it slow.
So, if somebody still has a problem with the performance, he needs to reset the device first and use a firmware of 1.93RC2 or newer. If that is not helping -> wireshark.

1 Like

You need to update the shelly, too.
The new RC firmware can be downloaded here:

http://repo.shelly.cloud/firmware/rc/

and pushed to the device via:
http:///ota?url=http://repo.shelly.cloud/firmware/rc/SHSW-1.zip
(Be aware: you have to use the right filenames for you devices! SWSH is e.g. for a Shelly1)

Please do only use it to test the CoAP bug.

@Phuturist
There is still a bug, that if you remove the URLs and reboot the shelly, the URLs are back againā€¦
It seem not to be stored persistantly.

Cheers.

Sounds more like a Shelly firmware bug. Iā€™m using the method as described in the REST API documentation. Iā€™ll do some testing myself but will pass it on to Allterco Robotics if I can reproduce.

opened a ticket at shelly

I know wireshark but how can I capture these packets?

@Sebastian_Lotz
So I need to update the Shelly application, upgrade the firmware and then remove the action links from homey? When I reset the Shelly device the http actions are empty and disabled, but is it still using them somewhere?

I can not reproduce this on a Shelly 1. I still had the HTTP report URLā€™s and triggered an action event resulting in the removal of the HTTP report URLā€™s. I then rebooted the device directly after that through the device settings and the URLā€™s did not return.

Are your Shelly devices connected to the cloud? Perhaps itā€™s syncing setting with the cloud and restoring them after a reboot. And did you also reboot directly after the removal of the HTTP URLā€™s.