Read bytes v2 fixes

[netmindz]

Trying to fix issue

[netmindz]

Don't think clear is working as you expect @fherbert

Unknown message start Byte: FF 1 bytes in buffer 1 bytes in buffer after clear Unknown message start Byte: FF 5 bytes in buffer 1 bytes in buffer after clear Unknown message start Byte: FF 2 bytes in buffer 1 bytes in buffer after clear Unknown message start Byte: FF 5 bytes in buffer 1 bytes in buffer after clear Unknown message start Byte: FF 1 bytes in buffer 1 bytes in buffer after clear Unknown message start Byte: FF 4 bytes in buffer 1 bytes in buffer after clear

[fherbert]

Doing a bit more reading, the ardunio serial library operates asynchronously. I foolishly assumed that after returning from tub.write the data would be sent, but this isn't the case. If we want to wait until the data is sent and then clear the receive buffer we need to run tub.flush(), this will wait for the transmission of serial data to complete, then we should be able to clear the receive buffer and get rid of the complete FB command. Probably just uncommenting and changing this line to tub.flush(false); (this waits for tx to complete and clears the rx buffer) should get it working how I'm expecting - but it will block until the FB command has been sent, don't think that's too much of an issue. I'll do some testing and find out.

I might also look into seeing if we can use the uart events and use a global state variable to indicated if we are sending a command, that way we can still work asynchronously.

[fherbert]

I've pushed a couple of changes to my branch, the main one's being waiting until the tx buffer is empty, then clearing the rx buffer and also reading the unknown byte out of the receive buffer so we don't always read the same invalid start byte Are you able to test this without merging into master? I've tested it on my spa, and I get the following:

Connecting to AP..
Connected with IP: 10.0.0.128
Setting pin 22 LOW
Setting serial port as pins 19, 21
Set serial port as pins 19, 21

Connecting to Wifi.
Connected to 'AP'

IP address   : 10.0.0.128
MAC address  : 50:02:91:A5:93:CC 
mDNS started : hottub-sensor.local
WebOTA url   : http://hottub-sensor.local:8080/update

Configuring WDT...
End of setup
YAY: command response : 20
Sent temp data 16.500000
YAY: command response : 20
YAY: command response : 20
YAY: command response : 20
[0] Connected from 10.0.0.19 url: /
{"type": "status", "data" : { "temp": "16.5", "heater": true, "light": false, "mode": "-1", "uptime": 30, "state": "Circulation ?" } }
YAY: command response : 20
YAY: command response : 20
Sent target temp data 39.000000
YAY: command response : 20
YAY: command response : 20

[netmindz]

Yeah the flush was commented out while struggling with sending the message before pin went high, but we know now that was due to message being twice the length, so should go back to having the flush.

Reading rather than peek and then flushing the buffer is better approach to handling any unexpected data

Yeah I can test before merge, just have to clone your repo and switch to your branch with the fix. I had just been lazy as I wrongly assumed that your PRs were tested fixes rather than draft proposals

[netmindz]

I tried your latest code, but was still seeing FB messages, so just decided to just consume them. That way we at least know if they are from the genuine panel or our own, which might help debug

[netmindz]

So the FB command I'm seeing is definitely what my real top panel is sending

[fherbert]

I'm printing out all the commands I receive but don't see any FB messages, only FA and AE showing in my log. I wonder what is different.

[netmindz]

You are on the 2 port, not the 3 port controller aren't you?

[fherbert]

Yes I am, are you able to check if your pin5 goes low when your panel isn't selected? Thats the only way I can think we can be reading in FB messages. My FB mqtt topic is never populated with any data.

[netmindz]

I'm counting it as an "unexpected feature" as it gives me an easy way to capture my panels FB commands without having to swap over over to a different sketch and if the user with the ML700 panel has the same behaviour as I'm seeing then I can upgrade my emulation from ML500 to the full ML700 feature set