Just checked, nothing special in there. Only one ‘EHOSTUNREACH’ error for a device on IP 192.168.1.4, as it seems during pairing. Homey is telling it cant reach the device, most likely due to bad connection or bad network routing. If it is related to the router in use is not something I can tell from the log. All I can tell is that this is not something with the app.
192.168.1.4? It’s already on 192.168.1.50 ip. Can you check this one 002fa798-cc21-477a-b777-61bd266fe608
cause: Error: connect EHOSTUNREACH 192.168.1.4:80
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16) {
errno: -113,
code: 'EHOSTUNREACH',
syscall: 'connect',
address: '192.168.1.4',
port: 80
}
}
Logs dont lie. And you should use static IP addresses. If you changed things around you should reboot Homey (and possibly the Shelly as well) as the mDNS implementation seems to do aggresive caching.
Oh, will try to reboot Homey
Wow, its really was a mDNS aggresive caching, after reboot 2.5 was discovered, but Shelly Plus 2pm disappeared from list, so I added it manually!
I think you should write about it in the description that mDNS search caches, and need a Homey reboot 
Thank you!
As in, you didnt believe me … 
I believed, I just haven’t encountered it before
I have 2 Door window sensors. The first shows battery level. The second shows a question Mark. What am I dooing wrong.
Be patient, it will update when the value changes. Battery operated devices aren’t polled because they sleep most of the time. Status relies on updates from the device itself.
1 Like
Dear Futurist,
to wake up a device such as the Shelly H&T, for example, if powered via USB/Micro USB cable, it is sufficient to disconnect the power supply for 15 or 20 seconds and then restore it.
This way everything is faster and simpler!
Homey Pro, through the Shelly App, immediately added the Shelly H&T… 
See you soon!
Today I had the same problem, I also created a diagnostic report: 080c0225-e81c-4403-956d-6dd506197d0d
I hope this will help.
As mentioned in the reply to your diagnostic report. This is caused by a bug in Homey Cloud. You should report it to Athom. A work around is to reinstall the app from the app store to force a app restart and restore the connection.
I reinstalled the Shelly app several times until now to fix the problem. The same issue happened 10 mins ago.
Interesting, because I have problems with this connectivity only with Shelly devices. All other devices are working without any problem and I don’t need to reinstall their apps to fix connectivity issues.
What’s interesting about it? The explanation behind it is really simple. Homey Cloud talks to Shelly Cloud (over websocket connection). If this connection breaks for some reason, which can happen, (for instance a re-deploy on Shelly Cloud) and the connection cant be restored because the restore mechanism fails due to a bug in Homey Cloud this only affects Shelly devices. Nothing complex about it. I have reported it to Athom a while back, they choose not to give this a priority. Now I ask the users affected by this to report this to Athom as well to get it higher on their backlog. But it’s not my issue to solve!
My two personal cents, this is why you do not want your home automation to rely on cloud connectivity.
1 Like
Thanks for the explanation, now I understand.
I’ve just installed a Shelly RGBW2 and try to change the dimlevel white, but cant get it to work from Homey. The command works fine directly from browser.
What am I doing wrong?
Any easier way?
Use color/0?turn=on&white=60 instead of the full URL.
1 Like
Diag: 585c8411-767a-48e9-89ed-54e484f1e51f
Shelly Pro 2, second channel does not react on commands from homey, but status is updated in Homey when controlled from Shelly phone app.
What I see in the Shelly device debug log is that no command is received for channel 1 (switch:1) by the Shelly Pro 2 from Homey.
According to this log there are some authorization issues. Have you tried removing and re-pairing the device to make sure everything is set up correctly?
Thanks for replies.
Ok, it now works, repairing with user admin and the password I had chosen. During previous pairing I had not used admin as username, but left the field empty.
Still a bit strange that switch:0 did work without the username and switch:1 not. Normally when credentials are wrong nothing works.
