search

dkjonas / Wavin-AHC-9000-mqtt

Esp8266 mqtt interface for Wavin AHC-9000/Jablotron AC-116
MIT License
82 stars 35 forks source link

MQTT feedback of set temperature missing? #20

Closed Baldorian44 closed 4 years ago

Baldorian44 commented 4 years ago

Hello. First of all i want to thank you for all the effort put into this task, it's truly great. I've been wanting this for a long time, good I had a friend who pointed me to this commit.

I seem to have everything working now with your setup (great guide!), except 1 thing. I can't seem to figure out how to fix it though!

When I change the temperature in a thermostat card inside Home Assistant (Or even go to the developer screen and set state) it sends the MQTT command as it should, the AHC9000 receives the data (as I can see the physical thermostat targeted updates into the correct "target temperature" set)... But I do not seem to get any feedback on this (is this as intended)? Instead i see the temperature in thermostat card in HA resets/changes back to whatever it was previously. And when looking into the climate class for the given sensor the temperature is unchanged (Even if i restart HA the temperature is not updated to whatever I send (But as mentioned the physical thermostat is!)

image

My setup:

  1. Nodemcu1.0 (changed that in your build file)

  2. Using MQTT Broker in HA (Using automatic discovery mode, without it I can't seem to get it work even with your example...)

  3. Follow your circuit board, but i do not have the 24V divider to 3V3 yet, so made the circuit without and powering the ESP via USB.

  4. Network connection seems fine, even tried putting a rather long network cable to the AHC9000 to get it closer to the router..

  5. Just to make sure I've explained it right I'll try to give an example:

  6. I Open thermostat card in HA, change temperature from 20°C --> 22°C

  7. The thermostat card temperature turns red while i change it (leaving it at 22°C), after 1-2 seconds it turns black (Stays at 22°C), around 2-3 seconds after that it just flips back to 20°C...

  8. I also have the issue if I change the temperature from the physical thermostat, it doesn't seem to update into HA or being transmitted...

  9. I've tracked the MQTT broker in HA sending the correct info, see next point

  10. image

Another note, as you can see in the first attachment the "target_temp_step: 1", a step size of 1°C is rather high, so that's why i tried to add it manually to change that to 0.5, but without luck so far as mentioned.

Hope you can help me out or have any idea why this behavior could happen. Thank you in advance.

dkjonas commented 4 years ago

I know about the step size. Will fix it later.

The expected behavior is that HA shows the set temperature.

When you set the temperature with /target_set, you should get a new message on /target with the new target temperature. As far that I remember, they are sent with retain-flag, so you should be able to see them without changing the temperature. Do you have any of these messages?

Baldorian44 commented 4 years ago

Thanks for the quick response!

No I do not receive anything after i see it has been transmitted. I haven't figured out how to run the Mosquitto commands from e.g. putty to the Raspberry HA is running on though, so I've only used Node-Red plugin for HA but it seems to track all messages and do what i do see here, like when a measured temperature changes.. So when i use /target_set it's by changing a temperature via a thermostat card (Which i dont think is the issue).

E.g. I don't understand where you can write (what's in your guide): mosquitto_pub -u username -P password -t heat/floorXXXXXXXXXXXX/1/target_set -m 20.5

I just think it's very weird the value i send(22°C) works for the thermostats but even if i reboot the ESP or HA I still read the value from the AHC to be 20°C...

dkjonas commented 4 years ago

On the RPI you need to install mosquitto-clients. Then you can execute the command in the terminal. See https://randomnerdtutorials.com/how-to-install-mosquitto-broker-on-raspberry-pi/

Baldorian44 commented 4 years ago

I've tried your way in an alternative (Using embedded SSH server on HA) and got it to live update when MQTT messages are being send/received, it's the same as previously, no data is received after it has been set

dkjonas commented 4 years ago

I'm a little busy the next weeks, so I don't have much time to spend on this. But please post the output of mosquitto_sub -u username -P password -t heat/# -v Just want to see if you are missing any other messages.

dkjonas commented 4 years ago

And try to remove power, wait one minute, and apply power again while logging the output with the above command.

Baldorian44 commented 4 years ago

I know that feeling, story of our lives, always busy :) Thanks for your feedback though so far - i'll eagerly await your feedback.

Are you system still working fine when you change the temperature? (Could it be related to some bug in a MQTT broker update or home assistant e.g.?)

Hereby the output (All of them are with QoS = 0 and retain-flag = true):

Before taking power: 2/16/2020, 11:25:08 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/6/target : msg.payload : string[4] "21.0" 2/16/2020, 11:25:08 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/6/mode : msg.payload : string[4] "heat" 2/16/2020, 11:25:08 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/6/current : msg.payload : string[4] "23.3" 2/16/2020, 11:25:08 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/6/battery : msg.payload : string[2] "80" 2/16/2020, 11:25:08 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/6/output : msg.payload : string[3] "off" 2/16/2020, 11:25:26 PM node: 204ad45a.2ee0fc msg : string[30] "No pushover keys configuration" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/online : msg.payload : string[4] "True" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/0/target : msg.payload : string[4] "21.0" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/0/current : msg.payload : string[4] "22.2" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/0/mode : msg.payload : string[4] "heat" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/0/battery : msg.payload : string[2] "40" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/0/output : msg.payload : string[3] "off" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/1/current : msg.payload : string[4] "22.8" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/1/mode : msg.payload : string[4] "heat" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/1/battery : msg.payload : string[2] "80" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/1/output : msg.payload : string[2] "on" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/1/target : msg.payload : string[4] "23.0" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/3/target : msg.payload : string[4] "21.5" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/3/current : msg.payload : string[4] "24.3" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/3/mode : msg.payload : string[4] "heat" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/3/battery : msg.payload : string[2] "10" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/3/output : msg.payload : string[3] "off" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/4/target : msg.payload : string[4] "23.5" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/4/mode : msg.payload : string[4] "heat" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/4/current : msg.payload : string[4] "23.3" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/4/output : msg.payload : string[3] "off" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/4/battery : msg.payload : string[2] "80" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/5/target : msg.payload : string[4] "20.0" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/5/mode : msg.payload : string[4] "heat" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/5/current : msg.payload : string[4] "23.3" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/5/output : msg.payload : string[3] "off" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/5/battery : msg.payload : string[2] "80" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/6/target : msg.payload : string[4] "21.0" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/6/mode : msg.payload : string[4] "heat" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/6/current : msg.payload : string[4] "23.3" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/6/battery : msg.payload : string[2] "80" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/6/output : msg.payload : string[3] "off" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/7/target : msg.payload : string[4] "22.0" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/7/current : msg.payload : string[4] "22.5" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/7/mode : msg.payload : string[4] "heat" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/7/battery : msg.payload : string[2] "80" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/7/output : msg.payload : string[3] "off" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/8/target : msg.payload : string[4] "23.0" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/8/mode : msg.payload : string[4] "heat" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/8/current : msg.payload : string[4] "22.6" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/8/output : msg.payload : string[2] "on" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/8/battery : msg.payload : string[2] "80" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/9/current : msg.payload : string[4] "21.8" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/9/mode : msg.payload : string[4] "heat" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/9/battery : msg.payload : string[2] "50" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/9/output : msg.payload : string[3] "off" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/9/target : msg.payload : string[4] "22.0" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/10/target : msg.payload : string[4] "22.0" 2/16/2020, 11:25:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/10/mode : msg.payload : string[4] "heat" 2/16/2020, 11:25:28 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/10/current : msg.payload : string[4] "22.6" 2/16/2020, 11:25:28 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/10/output : msg.payload : string[3] "off" 2/16/2020, 11:25:28 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/10/battery : msg.payload : string[2] "80" 2/16/2020, 11:25:28 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/11/target : msg.payload : string[4] "22.5" 2/16/2020, 11:25:28 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/11/mode : msg.payload : string[4] "heat" 2/16/2020, 11:25:28 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/11/current : msg.payload : string[4] "22.4" 2/16/2020, 11:25:28 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/11/battery : msg.payload : string[2] "80" 2/16/2020, 11:25:28 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/11/output : msg.payload : string[3] "off" 2/16/2020, 11:25:28 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/2/target : msg.payload : string[4] "21.5" 2/16/2020, 11:25:28 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/2/mode : msg.payload : string[4] "heat" 2/16/2020, 11:25:28 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/2/output : msg.payload : string[3] "off" 2/16/2020, 11:25:28 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/2/current : msg.payload : string[4] "21.8" 2/16/2020, 11:25:28 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/2/battery : msg.payload : string[3] "100"

Removed power here and put back in:
2/16/2020, 11:28:18 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/online : msg.payload : string[5] "False" 2/16/2020, 11:28:27 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/online : msg.payload : string[4] "True" 2/16/2020, 11:28:28 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/0/target : msg.payload : string[4] "21.0" 2/16/2020, 11:28:29 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/0/output : msg.payload : string[3] "off" 2/16/2020, 11:28:29 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/0/current : msg.payload : string[4] "22.2" 2/16/2020, 11:28:29 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/0/battery : msg.payload : string[2] "40" 2/16/2020, 11:28:30 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/1/target : msg.payload : string[4] "23.0" 2/16/2020, 11:28:30 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/1/mode : msg.payload : string[4] "heat" 2/16/2020, 11:28:30 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/1/output : msg.payload : string[2] "on" 2/16/2020, 11:28:32 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/2/target : msg.payload : string[4] "21.5" 2/16/2020, 11:28:32 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/2/mode : msg.payload : string[4] "heat" 2/16/2020, 11:28:32 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/2/output : msg.payload : string[3] "off" 2/16/2020, 11:28:34 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/3/target : msg.payload : string[4] "21.5" 2/16/2020, 11:28:35 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/3/output : msg.payload : string[3] "off" 2/16/2020, 11:28:36 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/4/target : msg.payload : string[4] "23.5" 2/16/2020, 11:28:36 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/4/mode : msg.payload : string[4] "heat" 2/16/2020, 11:28:36 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/4/output : msg.payload : string[3] "off" 2/16/2020, 11:28:36 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/4/current : msg.payload : string[4] "23.3" 2/16/2020, 11:28:36 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/4/battery : msg.payload : string[2] "80" 2/16/2020, 11:28:38 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/5/mode : msg.payload : string[4] "heat" 2/16/2020, 11:28:38 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/5/output : msg.payload : string[3] "off" 2/16/2020, 11:28:38 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/5/current : msg.payload : string[4] "23.3" 2/16/2020, 11:28:38 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/5/battery : msg.payload : string[2] "80" 2/16/2020, 11:28:39 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/6/target : msg.payload : string[4] "21.0" 2/16/2020, 11:28:39 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/6/mode : msg.payload : string[4] "heat" 2/16/2020, 11:28:39 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/6/output : msg.payload : string[3] "off" 2/16/2020, 11:28:39 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/6/current : msg.payload : string[4] "23.3" 2/16/2020, 11:28:39 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/6/battery : msg.payload : string[2] "80" 2/16/2020, 11:28:40 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/7/target : msg.payload : string[4] "22.0" 2/16/2020, 11:28:41 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/7/output : msg.payload : string[3] "off" 2/16/2020, 11:28:41 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/7/current : msg.payload : string[4] "22.5" 2/16/2020, 11:28:41 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/7/battery : msg.payload : string[2] "80" 2/16/2020, 11:28:42 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/8/target : msg.payload : string[4] "23.0" 2/16/2020, 11:28:42 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/8/mode : msg.payload : string[4] "heat" 2/16/2020, 11:28:42 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/8/output : msg.payload : string[2] "on" 2/16/2020, 11:28:42 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/8/current : msg.payload : string[4] "22.6" 2/16/2020, 11:28:42 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/8/battery : msg.payload : string[2] "80" 2/16/2020, 11:28:43 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/9/target : msg.payload : string[4] "22.0" 2/16/2020, 11:28:43 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/9/mode : msg.payload : string[4] "heat" 2/16/2020, 11:28:43 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/9/output : msg.payload : string[3] "off" 2/16/2020, 11:28:43 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/9/current : msg.payload : string[4] "21.8" 2/16/2020, 11:28:43 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/9/battery : msg.payload : string[2] "50" 2/16/2020, 11:28:44 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/10/target : msg.payload : string[4] "22.0" 2/16/2020, 11:28:44 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/10/mode : msg.payload : string[4] "heat" 2/16/2020, 11:28:44 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/10/output : msg.payload : string[3] "off" 2/16/2020, 11:28:44 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/10/current : msg.payload : string[4] "22.6" 2/16/2020, 11:28:44 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/10/battery : msg.payload : string[2] "80" 2/16/2020, 11:28:45 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/11/target : msg.payload : string[4] "22.5" 2/16/2020, 11:28:45 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/11/mode : msg.payload : string[4] "heat" 2/16/2020, 11:28:45 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/11/output : msg.payload : string[3] "off" 2/16/2020, 11:28:45 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/11/current : msg.payload : string[4] "22.4" 2/16/2020, 11:28:45 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/11/battery : msg.payload : string[2] "80" 2/16/2020, 11:28:48 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/0/mode : msg.payload : string[4] "heat" 2/16/2020, 11:28:51 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/1/current : msg.payload : string[4] "22.8" 2/16/2020, 11:28:51 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/1/battery : msg.payload : string[2] "80" 2/16/2020, 11:28:53 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/2/current : msg.payload : string[4] "21.8" 2/16/2020, 11:28:53 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/2/battery : msg.payload : string[3] "100" 2/16/2020, 11:28:54 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/3/mode : msg.payload : string[4] "heat" 2/16/2020, 11:29:01 PM node: 66c75829.dd8118 heat/floorDC4F220FB38A/7/mode : msg.payload : string[4] "heat"

Baldorian44 commented 4 years ago

Just wanted to point out i changed Platformio.ini to use the Nodemcu 1.0 (v2) instead of 0.9 (v1), but i do not hope that means anything....

[env:nodemcuv2]
platform = espressif8266
board = nodemcuv2
framework = arduino
upload_speed = 115200
lib_deps = 
    PubSubClient@2.6
build_flags = -D MQTT_MAX_PACKET_SIZE=1024

#[env:nodemcu]
#platform = espressif8266
#board = nodemcu
#framework = arduino
#upload_speed = 115200
#lib_deps = 
    #PubSubClient@2.6
#build_flags = -D MQTT_MAX_PACKET_SIZE=1024
dkjonas commented 4 years ago

I don't think that is the cause.

It looks like you get the /target correctly - just not when you change it. Try changing the target, and wait for HA to switch back to the wrong value. Then remove power, wait a moment and reapply. Does the value in HA then change to the correct one?

Baldorian44 commented 4 years ago

Yes dkjonas that actually works! it gets the correct /target back after the reboot, so i guess we can conclude it may be something in the ESP

Just tried a new ESP and a new MAX3072EEPA+, didnt work, exact same results.

Baldorian44 commented 4 years ago

I did a bit more testing today and observed another undesired behavior that might be related.. It seems like after i reboot the ESP it does not always receive the /target for all thermostats (And it is only the /target i do not receive, the rest I do always)

Example here where Bryggers (Didnt manage to translate to english yet :)), Hallway update correctly but the bathroom never received the /target during startup... image

I've tried to do some digging in the code (dont know if this helps you or not, but here goes):

The only place this value for /set_target can be updated is from mqttCallback function that should react as there is a "subscribe" to /set_target in the loop() when creating the mqtt connection. This then changes the target temperature (I can conclude this step must work as we can get the correct value after restart, plus the thermostats update (Except for some thermostats not sending /target)):

if(topicString.endsWith(MQTT_SUFFIX_SETPOINT_SET))
  {
    uint16_t target = temperatureFromString(payloadString);
    wavinController.writeRegister(WavinController::CATEGORY_PACKED_DATA, id, WavinController::PACKED_DATA_MANUAL_TEMPERATURE, target);
  }

As far as i can read, the code checks if the target temperature has changed every 5000ms (And this value should have changed once the write process completes above?):

          if (wavinController.readRegisters(WavinController::CATEGORY_PACKED_DATA, channel, WavinController::PACKED_DATA_MANUAL_TEMPERATURE, 1, registers))
          {
            uint16_t setpoint = registers[0];

            String topic = String(MQTT_PREFIX + mqttDeviceNameWithMac + "/" + channel + MQTT_SUFFIX_SETPOINT_GET);
            String payload = temperatureAsFloatString(setpoint);

            publishIfNewValue(topic, payload, setpoint, &(lastSentValues[channel].setpoint));
          }
dkjonas commented 4 years ago

Your understanding of the code is correct. I can't see any reason why the code is not able to read back the set target. Well, it could be a communication error, which discards the reply from the AHC. But as you have tested with different hardware, this is not likely.

In you first message, you state that you supply the esp from USB. How are your connections to the AHC? A and B is connected, but did you also connect pin 1/2 0v to Gnd of the esp/max3072?

An other thing you can try. Add: lastSentValues[id].setpoint = LAST_VALUE_UNKNOWN; after the writeRegister in the callback. This will force the main loop to send the /target message even if it thinks nothing has changed.

Baldorian44 commented 4 years ago

Thanks for feedback :)

Yes i have grounded pin 1 and 2 from the RJ45 port (to both esp and max3072) I tried adding your line of code and now the /target temperature seem to switch to 20°C in some rooms?? (where i have a different settings).

  if(topicString.endsWith(MQTT_SUFFIX_SETPOINT_SET))
  {
    uint16_t target = temperatureFromString(payloadString);
    wavinController.writeRegister(WavinController::CATEGORY_PACKED_DATA, id, WavinController::PACKED_DATA_MANUAL_TEMPERATURE, target);
    lastSentValues[id].setpoint = LAST_VALUE_UNKNOWN;
  }

Yet the problem persists, it sends the /target_set value, but nothing is returned :(

Baldorian44 commented 4 years ago

Hello.

Think I may have located at least some of the problem. After some debugging by creating a webserver in the ESP, as the serial communication is used by the RJ45 port) it appears that this line of code is only run during start (meaning only once):

// Read the current setpoint programmed for channel
if (wavinController.readRegisters(WavinController::CATEGORY_PACKED_DATA, channel, WavinController::PACKED_DATA_MANUAL_TEMPERATURE, 1, registers))
{
   uint16_t setpoint = registers[0];

   String topic = String(MQTT_PREFIX + mqttDeviceNameWithMac + "/" + channel + MQTT_SUFFIX_SETPOINT_GET);
   String payload = temperatureAsFloatString(setpoint);
   AmountTempSetRead++; // My counter to verify it doesnt enter...

   publishIfNewValue(topic, payload, setpoint, &(lastSentValues[channel].setpoint));
}

The interesting part is that "Mode" and "CurrentTemp" are functioning, but not the "SetTarget". "Status" seems also to not get through every time... I think this is not intended, but perhaps you know more? Any insight would be helpful, before i attempt to debug further in "WavinController::recieve". You can see my overview here of results: image

Even tried to increase timeout from 1s to 2s, didnt help either

dkjonas commented 4 years ago

The register should always be read, so your counter should increase. The most likely problem is a communication error. Either in WavinController::recieve or WavinController::transmit. I would suggest trying to dump the raw data packages to see why it fails.

You could also try to add a 120R resistor between A and B to properly terminate the bus.

Baldorian44 commented 4 years ago

I had a scope on two days ago where I only used transmit/receive for set temperature on channel 0 only. It showed that the first transmission is correctly transmitted and received, after that however it keeps transmitting (exact same message as the first, which I verified on the scope) but no response is coming.. But when I restart the ESP it can transmit/receive the first time again.. So yes it seems to be some sort of wrong / incorrect termination.

The 120ohm resistance you mention do you suggest it to be there continuously or only connect it to see if it helps getting one transmission through again?

jascdk commented 4 years ago

@Baldorian44 hi - could you post a picture of your setup ? I also had trouble the first time . The issue were totally mismatched termination 😃

dkjonas commented 4 years ago

120ohm is the proper way to terminate a rs422 bus, but wit short cable lengths and limited speed, it shouldn't be necessary and no others have reported problems. If it works for you, just leave it. An other possibility is to try to increase the delay in the WavinController::transmit function. It's currently 250us, but by calculation it should be at least 260 us. Never experienced any problems in this regard, though.

Baldorian44 commented 4 years ago

Hello.

I do not think there is noise on the signal (the 120ohm between A and B did nothing, unfortunately). I already tried the delay part, which did not work either.

I took a screen shot of my first data sequence which you can see further below, but i'll write the "findings" here. The data in my book looks just fine from the ESP side. However after the first one only the transmit part keeps running, with no response on receive end (Seen from ESP). But I figured out the the output on the other side of MAX3072 (A and B) is not even sending anything on the following transmits (Only the first), so that must mean the Wavin Controller is doing what it should, but the MAX3072 IC is not.... I have 2 of these IC's and they behave identical.. I will get some MAX3485 in some weeks I hope I can try instead...

I'll attempt to run some Power cycle on the IC to see if that will work... but i guess that shouldn't be standard! (Any thought is welcome!): UPDATE: Seems like power cycling did not work either, in fact if i had the MAX3072 off while the ESP starts up and afterwards turn the MAX3072 on, no data came through. Does the MAX3072 somehow need signals/pulse/message itself to start working? (Still annoys me I can load your entire program and then something comes through sometimes as mentioned in previous post)

Below you can see the first transmit/recieve from the ESP side: Channel 1 (Yellow): is RO (pin 1 on 3072) Channel 2 (Blue): is DI (pin 4 on 3072)

Overview: image

Zoom of Transmit: image

Zoom of Recieve: image

Below you can see the first transmit/receive from the RS422 side: Channel 1 (Yellow): A (pin 6 on 3072) Channel 2 (Blue): B (pin 7 on 3072)

Overview: image

Zoom of 1st RS422 sequence, which seems to contain the transmission data: image

Zoom of 2nd RS422 sequence, which seems to contain the receive data: image

Jascdk: I doubt i turned the RJ45 pins incorrectly as I saw in your post. It would be very weird that the first message gets through then :)

dkjonas commented 4 years ago

MAX3072 is pretty standard. I don't think replacing it with another type will change anything. Had a quick look at the datasheet, and nothing suggests it should enter a sleep mode.

If you don't get an output on A/B when the esp transmitting, then try measuring on /RE-DE to make sure the direction of the driver is set correctly (should be high during transmit).

Baldorian44 commented 4 years ago

Hello Jonas, Thanks for input!

It seems like my simplified code was prone to an error 40 (human error :)), it works flawlessly now if I want to send and receive one package (It was indeed the RE-DE that didnt behave correctly due to some coding mistake). But now that is fixed I attempted to run with 3 thermostats (only focusing on the /SetTemp still). And here we start seeing the original issue again, I do not receive all packages, have some screen shots below (they are not from the same sample, although they remain the same!). The RS422 seems a bit funny here for the 3rd message missing the feedback?

Somehow it seems to work to set the 3 temperatures from either the thermostat or HA. but when I add more traffic it starts not accepting all of the inputs.. so there seem to be some communication issues..... At least I seem to have verified that ESP transmits all it should.

Can I ask how many channels you use dkjonas? (I have 12)

Channel 1 (Yellow): /RE-DE Channel 2 (Blue): /RO (Pin 1)

image

Channel 1 (Yellow): /DI (Pin 4) Channel 2 (Blue): /RO (Pin 1)

image

Channel 1 (Yellow): /A (Pin 6) Channel 2 (Blue): /B (Pin 7) image

Baldorian44 commented 4 years ago

After additional testing i can actually get the /SetTarget, /Mode and /Status to work with all 12 channels without the code below, here i just put (1) in the if-sentence instead. The second I add this to the code it seems to mess everything up...

Adding my own value for "primaryElement" and set "allThermostatsLost = false" myself also seem to work. Even with reduced thermostats the code below still messes it up..

if (wavinController.readRegisters(WavinController::CATEGORY_CHANNELS, channel, WavinController::CHANNELS_PRIMARY_ELEMENT, 1, registers))
{
  uint16_t primaryElement = registers[0] & WavinController::CHANNELS_PRIMARY_ELEMENT_ELEMENT_MASK;
  bool allThermostatsLost = registers[0] & WavinController::CHANNELS_PRIMARY_ELEMENT_ALL_TP_LOST_MASK; 
  Read /Set Target; (Simplified)
  Read /Mode; (Simplified)
  Read /Status; (Simplified)
}
dkjonas commented 4 years ago

It is not really clear to me, what you have tried to change and the results.

I have 5 channels, but I know at least one other is running with 16 channels.

I'm wondering how your setup is? Are you using the same thermostat for multiple circuits? Do you use magnetic sensors? Display connected?

Baldorian44 commented 4 years ago

Hello dkjonas, I think i finally cracked it!

I added a bit of delay between each type of data that needs to be pulled and it seemed to do the trick (Testing on going, but i can set both temperature from thermostat and via HA now!)

I have 11 std. thermostats (12 channels as kitchen uses 2, that are merged), no magnetic and no display.

DELAY_BETWEEN_TRANSMISSION = 750;
I added that channel 5 is skipped (as that is not used for me, although it may not be needed)

if (wavinController.readRegisters(WavinController::CATEGORY_CHANNELS, channel, WavinController::CHANNELS_PRIMARY_ELEMENT, 1, registers))
{
  uint16_t primaryElement = registers[0] & WavinController::CHANNELS_PRIMARY_ELEMENT_ELEMENT_MASK;
  bool allThermostatsLost = registers[0] & WavinController::CHANNELS_PRIMARY_ELEMENT_ALL_TP_LOST_MASK; 
  delayMicroseconds(DELAY_BETWEEN_TRANSMISSION);
  Read /Set Target; (Simplified)
  delayMicroseconds(DELAY_BETWEEN_TRANSMISSION);
  Read /Mode; (Simplified)
  delayMicroseconds(DELAY_BETWEEN_TRANSMISSION);
  Read /Status; (Simplified)
  delayMicroseconds(DELAY_BETWEEN_TRANSMISSION);
}
Baldorian44 commented 4 years ago

Thank you very much for your help dkjonas, and thanks again for your awesome contribution! It seems to be running now, so i'll close the task :)

May I ask how old your Wavin system is? mine is from 2013, so perhaps it has an older Software? (Which could be why it behaves differently?)