Updated homey to version 5 yesterday, and 8 out of 10 shellys stopped working,
devices are working fine when accessed vie their web interface, but changing status from homey doesn’t work - EHOSTUNREACH, after that i’ve updated to v3 of app, and result was the same
what is interesting - status updates, such as temp or voltage - are working fine, only changing device state receives errors
any ideas what might be the problem or how this can be debugged?
Any news about supporting the Shelly Motion? I have it installed, but there is no easy way to use the lux-value in Homey. Motion webhook works like a charm!
Have you assigned static ip addresses for your Shelly’s in your router. Sounds like they have changed after being added. Make sure the ip address under device settings is correct.
Supported already in version 3 of the app. Only auto discovery is not working but this is a firmware bug in the Shelly motion.
Great, thanks. I will wait for v3!
Yes all addresses are static, the only change was homey version update
Try restarting the app and send me a crash report from the app settings page if the problem persists.
Could you re-try the master branch on Github.
Install the new version, re-add the shelly 1 with addon. Don’t work.
Yesterday update shellyforhass in my home assistant, the addon is already supported, is it possible that I can get some useful information?
Yes, please run the version from the debug branch on github and post the entire console log from app start-up and an update of the reed switch.
I think this is you are looking for:
(node:9103) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see Command-line API | Node.js v21.5.0 Documentation). (rejection id: 1)
(node:9103) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
2021-02-24 10:34:37 [log] [ManagerDrivers] [shelly1] [10] updating alarm_generic.external through CoAp for shelly1-483FDA91906C
(node:9103) UnhandledPromiseRejectionWarning: Error: invalid_capability
at Remote Process
Send you the full log in pm
v3.0.15 - 2021-xx-xx
- Made a more generic trigger card called “Input state changed” with tokens for which input changed and the new input state for devices that support one or more SW input terminals and/or external inputs. Flows that currently trigger for devices with more than one SW terminal need to be updated due to this to this generic trigger card.
- Added support for external switch for Shelly 1, Shelly 1PM and Shelly 1L
- Small improvements and bug fixes
For more information on installing version 3.x see [APP] Shelly - #1097 by Phuturist
This is most likely the release that will be published to all users in the stable channel if no more issues occur.
I’m not getting to use the card “input state changed” to activate flows.
I see the alarm_generic.external capability change from true to false, but I can’t use it to activate a relay or update the value of a virtual sensor. How would be the correct way to use this card?
The card is available under the device. You can add it as trigger to a flow. The card contains two tokens, one for the input that triggers the card and one for the new state. You will have to use logic condition cards to filter on these tokens and perform the actions you want. Your use case would be something like:
IF: trigger card input state changed
AND: token input = 'external switch 1"
AND: token state = ‘true’
THEN update virtual device to ON
Firstly, thank you so much for your work on this. The input state changed on my Shelly 1’s is exactly what I’ve been looking for so I can run them in detached mode.
My use case is with PIRs on the SW input and LED floodlights on the output. I’m aiming that any PIR motion (relay comes on for 3seconds then switches off) (switch input) will trigger a flow (camera snapshot). But in a separate flow, I check for darkness before switching on the associated LED flood (so it doesn’t activate the lights in the daytime).
I’ve checked the ‘input state’ of my shelly devices though and it does not change despite the Shelly app showing the blue ‘on’ for the button being activated. I’ve tried re-starting the app to no effect. (on - off with the button in homey works fine, but it appears the input state isn’t reading through). What have I missed?
thanks
Nothing, I see it still contains a bug. I’ll push a fix in a couple of minutes.
v3.0.16 - 2021-xx-xx
- Fix for the trigger card called “Input state changed”
For more information on installing version 3.x see [APP] Shelly - #1097 by Phuturist
This is most likely the release that will be published to all users in the stable channel if no more issues occur.
Wow, quick turnaround, thank you! Sadly this doesn’t seem to show the changed state when I look in the device page of the Shelly 1’s at the input state. I’ve installed and restarted 3.0.16 above. Should I be deleting and re-adding the devices as well?
While I’m begging help, my Shelly 3EM seems to have gone offline/ unreachable. I removed it and re-added (it was recognised ok and added successfully) but cannot be reached when attempting to click on the (3) devices that come up. Is this something I should add on github (whole new learning experience for me in taking part in bug reporting here).
Thanks again
I take it back, the Shelly 1’s are now permanently showing their input 1 state as Yes (don’t seem to reset when the input is removed?). I can hear the relay in the PIR clicking on and off, but the input state remains Yes at all times.
Can I check the usage for the input state in a flow is:
If: Input state changed
And: (Logic) State is exactly Yes
And: (Logic) Input is exactly input 1
Then: <whatever action/ flow I choose>
Thanks
Hello, i think its the PIR.
There must be some ballast to it put a light or a relais to the output of the pir.
And use the contact of the relais to give power to sw on shelly 1
Interesting, I did have this issue with my first PIR still passing enough voltage to keep the PIR powered, even when ‘off’ which seemed to be a lack of output resistance on the Shelly.
My current PIRs work fine in the case that they switch the light directly (via the input SW of the Shelly, they directly switch the output), so I wasn’t expecting that detaching the two in software would prevent the relay in the PIR from operating properly. This could be a Shelly issue I guess that means they can’t be used with PIRs in my case 
I was hoping more for a bug in the code, but that’s just because it’s easier for someone else to solve my problems!!
