So I want to incorporate my Shelly devices in HA. For that I need to change the CoIoT peer IP address to the address where HA is installed. If I do that, Homey can’t communicate with the Shelly devices anymore.
Is there a workaround for this?
- set CoIoT to mcast, downside is that using multicast drains the battery of battery operated devices like the motion sensor.
- use HTTP REST for Homey, downside is a not instant updates and actions events do not work
- use MQTT for HA
Hi @Phuturist , I just replaced my old homey 2016 model with a (used) Homey Pro. The new homey has a new IP, but the Shelly’s still point to the old CoIoT peer. Is there a way to force the device settings to get the new IP, or is this a manual action?
Manual for now, might add a maintenance action for this in the future.
Too bad! But no problem, let’s do it. Port 5683 is fixed right?
Yes, it’s the default port for CoAP.
1 Like
So there’s no downside for wired devices?
I must say, I love the CoAP feature. Have been using a motion sensor for a while now, and while it worked it was pretty slow to responding. I was changing the IP’s on all my Shelly devices and came across the motion sensor too. To my surprise it didn’t have the feature enabled, after that the response improved A LOT! great work, much appriciated!
I’m no networking expert, google on multicast versus unicast and you know as much as I do.
Ok will try that, yhanks for your responses.
Re-pairing did the trick indeed. Thanks!
I’m storing the shelly temperatures with prometheus (Homey App) & display them with Grafana. I have multiple devices which are reporting a temperature, eg. a weather station from netatmo or a temperature sensor from Gardena. The shelly app also reports a temperature, but the temperature is from the the device internally, which isn’t important for everyday use and doesn’t reflect a room temperature. The problem is, that the key/name of the value is “homey_device_measure_temperature” and will be used as well for my netatmo weather station or for my gardena sensor, so at the end I’ve to specify every single device instead of getting all “homey_device_measure_temperature” values to get rid of the shelly devices.
So long story short, in my point of view it would make sense to rename the temperature for the shelly eg. to “homey_device_measure_temperature_internal”.
In my screenshot you can see as well a real temp sensor key “homey_device_measure_temperature_1” for a temp sensor which is connected to a shelly 1, that makes sense.
I don’t know where prometheus gets it’s key from, but I’m guessing it’s derived somehow from the shelly app code. In the prometheus app I can’t configure anything.
Hope this makes sense. @Phuturist what do you think?
Although I understand your issue I wont be changing it. Using a default capability instead of a custom renamed one is much easier to maintain as the flow cards are auto generated for default capabilities. And some people actually depend on this default capability for other integrations which would break when changing it to a custom one. Next to that your situation is a corner case which will not benefit much users anyway.
1 Like
The README states:
The following metrics are exported:
…
- Device state information (sensor values, state of switches, etc.). Device state gauges are named
homey_device_<state>and have labels for device ID, name and zones.
I haven’t used Prometheus in a while, but can’t you create a query that would exclude Shelly devices?
homey_device_measure_temperature{name!~"^Shelly"}
That way, you can give all your Shelly devices a common (unique) identifier in their name to use as a filter in Grafana.
Although I understand your issue I wont be changing it
Ok got it. Some other app devs have done exactly what I suggested (gardena with the sensor eg.), but I fully understand your point. It’s truly corner case.
That way, you can give all your Shelly devices a common (unique) identifier in their name to use as a filter in Grafana.
Good Point, I could do that, but the name of the device would get even bigger than it is today.
My device name follows this schema today: (Room Name) (Device Name)
The bad thing here in my eyes is, you can create zones/rooms to split up everything, but if you create flows you don’t see the zone/rooms but just the names, hence if you have 10x ceiling light you need to have the room in the name as well to differentiate between them. So now if I have to add a key where I can filter for in Prometheus, the device Names gets even bigger than today (and of course with no additional value for my family members who are using the app and the devices).
Below a screenshot which shows my output today, a lot of sensor within my house with the key “homey_device_measure_temperature” and some un useful ones from the shelly (red marked). And thats not even the full output. I’ve about 50 shellys.
Ideally, the Prometheus app would add an additional label for the app id to each entry, so you would be able to filter on those.
Since the last update the ADC of the Shelly uni is not being readout anymore. Can this be fixed?
I have not changed anything in that area so I doubt it’s in issue in my app. Send me a diagnostic report and the output from http://shellyip/status, perhaps there is something in there.
Thanks for the quick response. I tried rebooting the wifi network, homey and the Uni. At first instance nothing fixed the problem. Everything was read out (temp sensors and contact status) but ADC value seemed to be stuck @0,86V while the real value was much different. The adc value was read out 11h ago while the rest was readout almost live. The next day the problem somehow fixed itself. Strange…
Hi,
Best way in my opinion is to toggle the hue lights with the “status from input” flow cards.
So for example; when Input has changed, then “switch on or off”
The other one is not working for me.
I have a few Shelly’s set up as a detached switch to control some hue Lights connected to Homey and this work fine 
.
