Open Docjones opened 2 years ago
Hi, it will be great if you make integration with the new product Shelly TRV. The valve works perfectly. The have the same error like @Docjones, but the valve is working and I log in on web UI with the its IP address. If we can help some way, please let us know.
Exactly the same response as above for me.
Are you sure the device is awake when use send that command? Is there a setting in the web UI to enable CoIoT or CoAP?
Device is awake, no access restrictions, CoIoT is set to "on", ip of the the homebridge-server, port defaults to 5683.
"describe" command still times out, but device shows up on homebridge-shelly-admin-view as "UNKNOWN"
Ok, I'm not sure why the device doesn't respond to description requests but it doesn't really matter. As long as it can be discovered, that's fine.
Can you confirm that the target temperature can be set using this URL:
http://<ip-address>/settings?target_t=20
Yes, temp has been set to 20°. Output was:
pi@homebridge:/var/lib/homebridge $ curl http://192.168.50.134/settings?target_t=20
{
"device": {
"type": "SHTRV-01",
"mac": "60A423D90E02",
"hostname": "shellytrv-60A423D90E02",
"num_outputs": 0
},
"wifi_ap": {
"enabled": false,
"ssid": "shellytrv-60A423D90E02"
},
"wifi_sta": {
"enabled": true,
"ssid": "XXXXX",
"ipv4_method": "dhcp",
"ip": null,
"gw": null,
"mask": null,
"dns": null
},
"mqtt": {
"enable": false,
"server": "192.168.33.2:1883",
"user": null,
"id": "shellytrv-60A423D90E02",
"clean_session": true,
"max_qos": 0,
"retain": false,
"update_period": 60
},
"sntp": {
"server": "time.google.com",
"enabled": true
},
"login": {
"enabled": false,
"unprotected": false,
"username": "admin",
"default_username": "admin"
},
"pin_code": "",
"name": "Heizung",
"fw": "20220202-080736/v2.1.3@d255ad74",
"discoverable": true,
"build_info": {
"build_id": "20220202-080736/v2.1.3@d255ad74",
"build_timestamp": "2022-02-02T08:07:36Z",
"build_version": "2022020208"
},
"cloud": {
"enabled": false
},
"coiot": {
"enabled": true,
"update_period": 3600,
"peer": "XXXX:5683"
},
"timezone": "Europe/Berlin",
"lat": xxxx,
"lng": xxxx,
"tzautodetect": true,
"tz_utc_offset": 3600,
"tz_dst": false,
"tz_dst_auto": true,
"time": "07:59",
"child_lock": false,
"display": {
"brightness": 7,
"flipped": true
},
"hwinfo": {
"hw_revision": "dev-prototype",
"batch_id": 0
},
"sleep_mode": {
"period": 60,
"unit": "m"
},
"thermostats": [
{
"target_t": {
"enabled": true,
"value": 20,
"units": "C",
"accelerated_heating": true
},
"schedule": true,
"schedule_profile": 1,
"schedule_profile_names": [
"Bad",
"Livingroom 1",
"Bedroom",
"Bedroom 1",
"Holiday"
],
"schedule_rules": [
"0430-0123456-25",
"0900-0123456-23",
"1800-0123456-25",
"0000-0123456-23"
],
"temperature_offset": 0,
"ext_t": {
"enabled": false
},
"boost_minutes": 30,
"valve_min_percent": 0,
"force_close": false
}
]
}
Oh, and can you include the battery level when integrating it? Can i provide you with help/information/output?
Great!
Yes the battery level will be included.
Hey @Docjones, can you install shellies ($ npm i -g shellies
) and then run $ shellies listen
. Is your TRV discovered by this script? Can you tell if the status
property reflects whether a target temperature is enabled? Does mode
refer to the currently active schedule?
Hello @alexryd - the TRV is not being discovered.
Besides: there is no option to pass authentication to the shellies
command - i receive multiple Error 401
while querying the settings of the other devices.
Is CoIoT set to the IP address of the device that you are running shellies
on? I'm not sure if this can run on the same device as homebridge. And is the TRV awake when you run that command?
Yes, CoIot ist set properly - however, since i don't have another machine (running npm), i only can test this from the homebridge server. The device is definitivel awake - i was checking it with the webinterface simultaneously
Hello @alexryd - any new on this issue? Anything i can provide you with to help to solve the issue?
What else can we do to support the TRV? My device is getting dusty little by little. Please let's try to solve the problem together again...
I get a time out with the command, but I can open the URL over web. For other devices like shelly1, the command ran...
xx@raspberrypi:~ $ homebridge-shelly describe 192.168.xxx.xxx
Error: No reply in 247s
at Timeout.
Here is the output from $ shellies listen:
[Device discovered] 2022-04-30T21:01:04.600Z Model: Shelly TRV ID: xxxxxx Host: 192.168.xxx.xxx Property: temperature Value: 20.9 Property: targetTemperature Value: 19 Property: battery Value: 99 Property: sensorError Value: false Property: valveError Value: false Property: mode Value: 0 Property: status Value: false Property: valvePosition Value: 0
@xelypse Ok so if your TRV can be discovered with the shellies listen
command then it can be supported by this plugin. Can you tell if the status
property reflects whether a target temperature is enabled? Does mode
refer to the currently active schedule?
Hi @alexryd, yes, mode
does refer to the currently active schedule and status
indicates whether the thermostat is currently heating.
TRV can be discovered with the shellies listen
command, but only if the TRV ist awake. Could this become a problem?
Hey @Docjones, can you install shellies (
$ npm i -g shellies
) and then run$ shellies listen
. Is your TRV discovered by this script? Can you tell if thestatus
property reflects whether a target temperature is enabled? Doesmode
refer to the currently active schedule?
I did this and $ shellies listen does not return the TRV.
Hey Alex, could you estimate by when the implementation can be completed? Sorry for pushing 🫣
I installed a few Shelly TRV devices in my home to maintain a constant temperature. Great devices, would be awesome to see them supported in this plugin!
Hi Alex, do you have an update for us? Are you planning any further development in this topic/plug-in? Thank you for any update regarding this! Steff
In case it helps anyone: Setting the coiot peer to the ip address, not the hostname, fixed the timeout issues for me. You'd think they are equivalent but nope.
The shelly TRV just silently fails at anything that'd require DNS resolution, even globally-resolvable DNS names.
If that doesn't help, you might get a little bit more of information with http://your-shelly-ip/debug/log
, but it only logs something when it receives coiot messages, the reply is silent and fails silently.
(Not a homebridge user but i found this while trying to solve my own problem)
I was able to get my homebridge to pickup a TRV by
excerpt from $ curl http://<TRV IP>/settings after it was configured
"coiot": {
"enabled": true,
"peer": "192.168.0.145:5683",
"update_period": 3600
}
The TRV then appears in the admin UI for homebridge-shelly at http://homebridge.local:8181/ - here's what the API returns
$ curl http://homebridge.local:8181/api/devices
{
"data": [
{
"excluded": true,
"host": "192.168.0.15",
"id": "<SNIP>",
"lastSeen": 784823,
"modelName": "Shelly TRV",
"online": true,
"type": "SHTRV-01",
"unknown": false
}
],
"success": true
}
Hello, I would love to see support for the Shell TRV as well. Using @danburke example, I managed to get my Homebridge picking up TRV, too. But it is unknown and excluded:
{
"success": true,
"data": [
{
"type": "SHTRV-01",
"id": "<#####>",
"host": "192.168.100.65",
"modelName": "Unknown Device",
"online": true,
"lastSeen": 29065,
"unknown": true,
"excluded": true
}
]
}
Putting a $100 bounty on a solution to this since I use this plugin a lot and very much appreciate all the work that goes into it. (Via PayPal)
Is there anything more we could do? I would really appreciate if this plugin would support the TRV. Thank you for any update on this. kind regards Stefan
I would also love a solution. If there is anything that can be done to support the effort let me know.
My last try, i really do not want to setup homeassistant only for my TRV's. Unfortunately. I guess there is no further development on this plugin, am i right?
Tried to do that on my neew Shelly TRV, command returned:
Perhaps this will help: https://shelly-api-docs.shelly.cloud/gen1/#shelly-trv