Issue when hex13 (and maybe hex11) in the the info messages

[sjeffrey101]

Ive got another issue with the flow control - when the checksum = hex13 (maybe any other byte also) it doesnt read the zone status correctly. i currently have 2 zones which are on, but showing off in HA as it cant read the zone status right, and update the status

incorrect checksum, ignoring 550b200000020200003831 check 85 calc 19 throw away early trim 0b20010000ff140000363655

took me a while to realise but the code is reading decimal 85 from the serial as the checksum (55 hex which is actually the start of next commend) - which then has to be thrown away.

the correct checksum is decimal 19 - hex 13 whcih is end of transmission window. i think the read stream ignores 11 and 13 and doesnt return it in the read even when its in the part of info message.

ive found that when pushing volume up on a couple of zones this will eventually occur, as the checksum reaches this number.

[sjeffrey101]

reference

ive forked the repository, and ive just re-written the serial part would be interested how it runs for you. Ive turned off XonXoff as it doesnt seem to work correctly (in my opinion). Would be interested in if you manage to get it working (2 issues)

also have a go with my code and see what you think. Personally i think it runs much better, and havent had any performance issues.

[mattsaxon]

I’ll look forward to testing it. If it performs well that’s good news, even if it makes the code less clean. Maybe we now know why Speakercraft don’t document they support XOnXOff!

so any ideas why the original implementation didn’t perform well for you?

[sjeffrey101]

yeah, its probably speaker craft not supporting it right. I did see somewhere then 11/13 should be encoded when its part of the message - which it is not.

to be honest i think i was trying to use the non async serial to begin with, then the implementation i did with async serial was not as good as yours, it was using a call back and the messages were fragmented. So i think i quickly gave up in favour of the ESP32 which was dedicated to serial interface and didnt miss a beat.

I was also wondering if at the time my USB 2 Serial wasnt the most reliable, as it would work fine for a while then just stop recieving the serial data. or maybe it was the serial pass thru from virtual box (which i was running at the time)

[mattsaxon]

Ok, yes I’ve read that too, so we essentially are not seeing an industry xonxoff protocol and therefore must implement ourselves.

Given this timing will now be much more important as you stated elsewhere. We might need to move from async to threads as per class serial.threaded.ReaderThread(threading.Thread) in pyserial docs.

probably not urgent if it is working for us, but if we have other integrations that are not well behaved for cooperative multitasking we may need it at some point.

[sjeffrey101]

see how you get on with it. When i send commands it seems to hit the first window so im not seeing performance issues at all. I think i have seen it miss the first window while HA was still booting, but because i leave the command in the queue until it is either confirmed or confirmed as invalid, then it will try in the next window any way.

my main concern is if poeple run on pi or something low powered.

what platform are you running?

this is also another reason i like to turn it off using a smart plug, when not in use, so it isnt using processing power just sat in standby.

stu

[mattsaxon]

I’m on a Pi 3b+

[sjeffrey101]

great, have you had a chance to test the code yet, or still away?

[mattsaxon]

Still away for another week or so I’m afraid.