Yes, it’s a bug in the code. I’ll fix it and let you know when I’ve pushed an update. Tks for the logs.
Ok, I’ve updated the code to better filter out corrupted f7’s. Those ready signals are most likely still due to that noisy receive line and sometimes a zero byte would get lost, shifting the data around. Anyhow, that should be caught now. The data looked ok in your log that I could tell but in my testing I was able to replicate the issue. Try it out and let me know if it fixes that issue.
I’ve installed it now and will keep an eye on it over the next few days. Thank you!
I was doing a bit more testing and the changes I did are not enough to catch all those missed bits so I don’t think it will fix your issue. Also, your logged f7’s don’t have any issues and yet, the ready flag was still turned off which does not make any sense as it was captured properly so I’m at a loss there.
Edit: I don’t think it is related to noise in this case after reviewing your logs. It happens on the refresh cycle (every minute). I don’t have the issue on my system but I only have the one keypad. On yours I see a few other keypads addressed on the f7 for the same partition. I will check my logic on that.
Thanks - yes, I’m still having errors, and I’m also still having noise on my system. Essentially, I have 3 devices acting a keypads in my system - I have the Honeywell 6160 physical keypad as ID 17 (why the installers didn’t just use the default 16 I don’t know), a Ademco SEM300 (my LTE communicator, it wants itself as keypad 23), and the ESP32 which I used to run on ID 18, but then I switched it to 16 just so I could make sure there were no extra IDs enabled on the panel). It doesn’t seem to make a difference in terms of noise however.
I’m trying to determine what could be causing the noise. The Parity errors show up about 5-6 times per hour, somewhat randomly but they do seem to be clustered together so I’m guessing it might be related to some chatty thing the SEM300 is doing. I see this 24x7, even when the house is quiet and everyone is asleep, so I don’t think it’s a specific sensor.
I tried disabling aui (settings auiaddr to 0) and that made no difference either.
I have logs of the last 16 hours or so if that’s helpful.
Another issue that causes a noisy line is a weak signal from the optocoupler. That’s another reason I’m not crazy about that design since it has to make some compromises to mitigate loading the data line too much by using a 4.7kohm resistor (for r6 and r8). Unfortunately that limits the current through the led a bit too much and causes a weaker signal on the transistor output. Why don’t you try putting a 10k resistor in parallel to the existing r6 4.7k resistor to lower the resistance and see if that helps the output. I’ll still dig in the code to try and find out why you are getting the flapping ready line.
Unfortunately my circuit board was printed at EasyEDA using the design at oshwlab that boobeechen posted. The R6 (and all of resistors) are tiny surface mounted bits that are beyond by ability to solder to. I had a hard enough time holding my hands steady to solder the headers for the ESP32! 
If it turns out the noise is really bad, I think I may have to do what everyone has done and buy a breadboard kit and parts and create a new circuit from scratch. I’d assume you’d still recommend the “Non-isolated simple version” in the notes.
Thanks for looking into the flapping ready line. So far, I can live with the noise as I don’t have anything that I can’t work around with that.
From what I see you have txpin = pin 21, rxpin= pin 22 and monitorpin = pin 19. Is that how you are setup in the yaml ?
It looks ok from what i see though.
I already found one major mistake. I put a 180K-ohm resister instead of a 180-ohm resister! I’ll fix it!!
EDIT: I got it all working finally. In addition to the 180-ohm resister, and getting the pin off by one that you caught, it turned out I also had a bad optocoupler. Thankfully that is socketed so it was trivial to swap it out with another.
I’ll keep an eye on it for the next few days and see if it has fewer parity errors.
If you think you will do more of these type of projects, a cheap usb oscilloscope or inexpensive handheld one would be a handy thing to have…
I don’t trust the color codes and always measure the resistors when I use them. Glad you got it all working… Frustrating at times to find bugs!
Unfortunately the new circuit behaves exactly like the old ones. I’m still getting parity errors and they seem to exactly the same frequency as before and at similar times. I also see the rdy_1 flapping every so often. Any luck finding out what was causing that?
Interesting. Definitively something causing interference or perhaps a power issue.
As to the ready sensor, I can’t really duplicate it here so hard to debug. The only time I’ve seen it happen is when I had a bad f7 packet but your previous log didnt have that issue so I’m still at a loss here.
Edit: I’ve made one small change that should help with invalid F7 cmds passing through the crc. It won’t fix the parity errors but should alleviate some of the rdy flapping from incorrect f7’s