Shelly Binding

? I already release a stable 2.4.1 (master branch)
and yes roller shutter works fine

what is the question?

In general the binding tries to initialize all things on startup. If this fails the thing stays in state INITIALIZING. The following conditions trigger a new initialization

  • every minute the status is checked and reinit is performed for OFFLINE devices
  • every sendCommand() triggers the initialization if the thing is OFFLINE
  • an incoming event triggers initialization
    on the next status update a new /settings and /status is performend.

As far as I could see the re-initialization is successful.

And yes I see those timeouts from time to time. Together with @igi we could verify that they are not related to the binding. Under certain conditions the device doesn’t response for 5-15sec. All http requests in that time window will not be responded. Without intervention the device comes back and processes further requests.
2 situations are identified and reproducible so far:

  • Shelly 1: the device doesn’t response to http requests when
    an auto timer for ON/OFF is configured
    the action urls are set and
    the relay output is set to IN ON via the API
    then the device stops responding to http requests for 5-15s
  • Shelly 2.5: scenario like the one before
    when pressing both buttons events gets issues,
    but device stops responding to http requests for 5-15sec

Nevertheless I have seen this behavior from time to time in other situations. I started to collect feedback to Shelly and will try to create some awareness to fix those issues and improve the API documentation - let’s see… Feel free to report other problems, which I could include in the report.

Could someone also confirm this problem:

  • Shelly1: After updating to FW 20190711-084053/v1.5.0-hotfix4@3b4f7414
    the API returns “update”:{“status”:“unknown”,“has_update”:false,“new_version”:"",“old_version”:“20190711-084053/v1.5.0-hotfix4@3b4f7414”}
    (worked fine with previous fw versions)

Thank you for feedback, so everything works as expected.

Kindest regards

let’s say: the binding is able to deal with the issue. In fact that’s a firmware bug.

On my fresh Windows OH installation I installed Gson 2.8.2 and activated it.Set the log to TRACE. Then I copied the latest shelly.jar file into the addons folder. I searched afterwards in the openhab.log file for “shelly” but could not find anything.Any idea what to do?

I created a post in the forum, maybe some other developer could help

are you also using Windows?
I have macOS and RPi, but @hmerk also saw that on Ubuntu

not on windows. RPi and Mac

did you tried the above jar?

yessssssss. and it worked on MacOS fresh install…

  1. Stopped the OH, and wait 30s
  2. started OH
  3. log:set TRACE org.openhab.binding.shelly
  4. added .jar file to the /addons folder.
  5. WOALA it worked…

maybe a bit later I will test on the RPI…

Thanks @markus7017

great! good job!
it seems that you downloaded the html file and not the jar or you saved the file here with a right-click, which doesn’t work - you need click on the link. This is a known problem with GitHub Links/Downloads or I posted the incorrect link. Could you please try again, you should get the same jar (from snapshot branch):

click on this link (do not use Save here) and then click on Download)

Could you please try the same

I just did a test on my Windows computer. And the binding is here!
This evening I am going to test it on my Raspberry Pi.
Thank you for your support!

Now it is working perfectly on my Raspberry Pi.
Thank you for your patience and the good work!

welcome :ok_hand:

Yes. that is working on RPI as well. Thanks…

I am using a Shelly1 in order to get back the positon of the manual external switch. This takes somethimes up to one minute.Is there any possibility to increase the speed of feedback or force an immediate feedback.

correct… I have this issue too…

There is and “update interval” setting in the Thing configuration, from PaperUI go and edit your Thing and click “show more”. It should appear.

Don’t go this way. This should be event based.

Which branch are you using? master or snapshot?
@igi and I saw API timeouts when using both event sources (button+output) and pressing both buttons on a 2.5 at the same time. I saw something similar with the Shelly1. We tried to work around by not setting the button event url, but that doesn’t solved the problem. Nevertheless this change was active in the snapshot for several days and has been removed in the latest snapshot-build.

If you experience this with the latest snapshot build oder the master branch I need a TRACE Log to see what happens.

Reducing the status interval increases the polling, which doesn’t make sense to catch the button or output events. You could verify in the Web UI if they are set correctly after the binding has started, both have to point to your OH system.

fyi: @Igi helped to organize a Dimmer freshly from the IFA and it’s supported in the snapshot branch :wink:

The other new devices could be supported when I get access to it.

1 Like