search

softypit / esp32_mqtt_eq3

esp32-based mqtt node to control EQ-3 BLE TRVs
145 stars 48 forks source link

Unboost causes 80% valve opening #9

Closed MeisterQ closed 5 years ago

MeisterQ commented 5 years ago

Hi, I added the 'poll' command for neatness and I don't actually use it with my heating-controller application. I have tested previously too and noticed the time got corrupted but hadn't realised it was the poll command that caused this. Unfortunately without a real-time-clock in the esp-32 (we could implement something but couldn't rely on access to ntp or a known accurate time reference) it is not possible to re-set the time on the unit for each poll. Assuming you do not use 'boost' mode with your trvs you can simply use the 'unboost' command which will have the same result as 'poll' without corrupting the time. Regards. Paul.

According to this i tried to replace the "poll" with the "unboost" command to update the state of the valves each 10 minutes.

It always gave me 80% valve opening back, and my Valves always changed the positions from e.g. 7% to 80%

softypit commented 5 years ago

Hi, I added the 'poll' command for neatness and I don't actually use it with my heating-controller application. I have tested previously too and noticed the time got corrupted but hadn't realised it was the poll command that caused this. Unfortunately without a real-time-clock in the esp-32 (we could implement something but couldn't rely on access to ntp or a known accurate time reference) it is not possible to re-set the time on the unit for each poll. Assuming you do not use 'boost' mode with your trvs you can simply use the 'unboost' command which will have the same result as 'poll' without corrupting the time. Regards. Paul.

According to this i tried to replace the "poll" with the "unboost" command to update the state of the valves each 10 minutes.

It always gave me 80% valve opening back, and my Valves always changed the positions from e.g. 7% to 80%

I've done a bit of testing and I can reproduce this too. It's not consistent though. Sometimes unboost makes no changes but sometimes it causes the valve to open to 80%. It looks like it is triggering boost but the display and BLE status do not show boost as being active. If I sequentially use 'boost'/'unboost' it seems to work OK. Sometimes I can also send repeated 'unboost' and all is well. This may be a bug in the trv software or perhaps there is some misunderstanding in the protocol reverse-engineering. Another way to 'poll' the device is to re-set the current mode (auto/manual) or re-set the lock state (lock/unlock). Either of these commands will generate the status response.

I've changed the 'poll' command to 'settime' and will test this for a little while then update the repo when I'm happy with it. This could also be used for polling provided you send the current time on each call.

MeisterQ commented 5 years ago

Hi, I added the 'poll' command for neatness and I don't actually use it with my heating-controller application. I have tested previously too and noticed the time got corrupted but hadn't realised it was the poll command that caused this. Unfortunately without a real-time-clock in the esp-32 (we could implement something but couldn't rely on access to ntp or a known accurate time reference) it is not possible to re-set the time on the unit for each poll. Assuming you do not use 'boost' mode with your trvs you can simply use the 'unboost' command which will have the same result as 'poll' without corrupting the time. Regards. Paul.

According to this i tried to replace the "poll" with the "unboost" command to update the state of the valves each 10 minutes. It always gave me 80% valve opening back, and my Valves always changed the positions from e.g. 7% to 80%

I've done a bit of testing and I can reproduce this too. It's not consistent though. Sometimes unboost makes no changes but sometimes it causes the valve to open to 80%. It looks like it is triggering boost but the display and BLE status do not show boost as being active. If I sequentially use 'boost'/'unboost' it seems to work OK. Sometimes I can also send repeated 'unboost' and all is well. This may be a bug in the trv software or perhaps there is some misunderstanding in the protocol reverse-engineering. Another way to 'poll' the device is to re-set the current mode (auto/manual) or re-set the lock state (lock/unlock). Either of these commands will generate the status response.

I've changed the 'poll' command to 'settime' and will test this for a little while then update the repo when I'm happy with it. This could also be used for polling provided you send the current time on each call.

Im trying "unlock" instead of "poll" now. Lets see if there are some crashes.

MeisterQ commented 5 years ago

@softypit Im using unlock now since friday evening. Its working just perfect instead of "poll"

softypit commented 5 years ago

I don't think there is anything that can be fixed on the ESP to prevent this unboost issue with the trvs. Can this issue be closed?

MeisterQ commented 5 years ago

I don't think there is anything that can be fixed on the ESP to prevent this unboost issue with the trvs. Can this issue be closed?

@softypit

Its ok for me. Im using "unlock" now, and its working fine.

You should just probably add this to the describtion

softypit commented 5 years ago

I added a wiki with a 'tips and advice' page. Please feel free to add useful info to the wiki.