Beiträge von raboof

Zitat

I have integrated them with Home Assistant integration the and HA reports the following in the log:

• Error fetching Badkamer TRV2 data: Sleeping device did not update within 3600 seconds interval
• Error fetching Badkamer TRV1 data: Sleeping device did not update within 3600 seconds interval

I'm not too familiar with HA, but it seems it's polling the HTTP endpoints. Does HA support MQTT? The TRV periodically checking and updating the MQTT topics might be able to deal with unstable connections better compared to polling...

I also see connection issues when I try to connect after not connecting for a while. Once I get a connection, it remains stable though.

Perhaps it preserves battery life by going into some kind of sleep mode after not actively using the wifi for a while, and needs some time to wake up from it?

When primarily using a protocol like MQTT it might not be a big deal that it checks the topic only at certain intervals and the wifi isn't reachable all of the time.

Zitat

The current version of the mobile app has calibration in settings. The web dashboard of the TRV has calibration too (I was using this one).

Ah, indeed it is in the web dashboard under 'settings' and hitting the /calibrate endpoint (that's documented for other Shelly devices but not this one) also works.

Zitat

But with the latest FW there is no neet to recalibrate, because the TRV regularly closes the valve tight and kind of recalibrates itself.

This is a lot noisier than before, but works

Hmm, I'm on the latest (20220115-083921/v2.1.2@3f3e56f8) and I think I noticed the radiator still warming up even after the valve being closed, perhaps I need a spacer (Detecting if a spacer is needed?). Will have to do some more proper testing later.

Glad your particular issue is now resolved, though :).

I assume the TRV calibration measures two values: 100% (where the actuator first hits the rod) and 0% (where the rod is at its maximum position, closing the valve).

When you calibrate the TRV while it is not connected, the calibration 'fails'. In what conditions does it fail? Only when it cannot determine the '100%' (open) value, or does it also make sure it could reliably determine the '0%' (closed) value?

Some forum threads around the radiator remaining warm even in 'closed' state recommend adding a 'spacer' helped for them - apparently the TRV physically couldn't completely close the valve. This suggests the calibration does not make sure it could reliably determine the '0%' (closed) value and just assumed 'all the way open'?

I think it would make sense for the calibration to fail when it can't determine the 0% (closed) value, signaling to the user they might need to add a spacer.

Alternatively, is there a way to get the calibration values through the API? In that case you could check if 0% was calibrated to 'all the way open' if your radiator remains warm and you suspect a spacer might be needed.

I see the logs (from /debug/log) do show some information:

Currentposition  before move: 1 direction: open
Currentposition  after move: 1690

Currentposition  before move: 1690 direction: close
Currentposition  after move: 5

...Total steps: 1645


Currentposition  before move: 1 direction: open
Currentposition  after move: 1666

Calibration passed



Last percent on boot: 0.00
Current position: 1666 - new:1645

I'm not sure how to read this, though - does this look like a successful calibration detecting both 'sides'?

Zitat

I don't think calibrating every day is a solution. (Although I made a tool to simplify the process and tracking of this issue.)

How do you trigger the recalibration? Hitting the physical 'reset' button works, but then it goes back into AP mode, which is a hassle to reconnect to the WiFi and re-configure the relevant settings.

Zitat

---------------------------------------SENDING------------------------------------------------------

MQTT Command Topic:

shellies/shellytrv-60A423D0D034/thermostat/0/command/target_t

Thanks so much! The 'thermostat/0' bit was missing from the docs at https://shelly-api-docs.shelly.cloud/gen1/#shelly-trv-mqtt but indeed appears to be required.

Zitat

Have a look ińto the official api description.

Do you mean https://shelly-api-docs.shelly.cloud/gen1/#shelly-trv ? There is a typo there: it says '/settings/thermostats/0' and '/thermostats/0', but it looks like that should be '/settings/thermostat/0' and '/thermostat/0'.

It would also be helpful to clarify that position '0' means 'the valve is closed'.

For MQTT, the device seems to be posting to 'shellies/shellytrv-<id>/info' and 'shellies/shellytrv-<id>/settings' topics, not shellies/shellytrv-<id>/status as mentioned in the docs.

Are the sources for the docs shared on git for external contributions somewhere?

I recently received my TRV, pretty impressed by the device so far!

I find the UX of the physical button a bit inconvenient: long-pressing and holding the up/down buttons to set the target temperature. I would much prefer to be able to toggle between 'high' and 'low' settings (with some preconfigured values for 'high' and 'low') with a simple short press.

I assume this is not possible with the official firmware, which is fine: one of the reasons I chose Shelly is because the company seems to be friendly towards custom firmware (e.g. tasmota).

Is there any information available about custom/opensource firmware options for the TRV yet?