05-11-2019, 04:50 PM
Sorry everyone, I feel horrible for the trouble I'm putting you through. I'm thinking there are two possible issues related to many.
One possible issue for some of you could be related to controller hardware. Controllers Rev-D and previous have a different circuit for communications between display and controller. With those boards there's a lower limit on the amount of data that can be sent through the serial port at once, if large strings of data is sent there's a good chance it's not all making. Back in the day I tried putting all the sensor data in a single variable so it could all be sent in one chunk but it was too much and it chocked. This is why I had you do that modification to some files in the Arduino IDE, it increased the buffer size for the serial ports, if that wasn't done the buffer would overfill before all data was sent.
On Rev-E controller boards I changed the communication circuit which improved it 10 fold and at that point a lot more data could be sent at once. Now in v5 all sensor data is assembled together and sent in one chuck which is likely too much for the older boards. I had to do that as sensors can now be disabled and sending one piece at a time was too slow for the display to update every second. I know Dom has Rev-D and I'm pretty sure that's why your temp sensors are freezing. Dom can you try disabling all the ports on the hardware connected screen so only one temp sensor is enabled. This will shorted the data to an amount that should be no issue. If you still have v5 installed try that. If you went back to v4.2 it's ok.
I'm not sure about the version of boards others have, I think your ok fietssnrex as I just gave you some updated boards and I don't think I would have given you old ones with the iffy communication circuit.
Now for the other issue which is probably affecting most of you and again seems related to older hardware. Back in the day when Nixu added power monitoring to his power bar he had lots of issues with the I2C hanging. We couldn't figure out why as it was quite random so Nixu found some code that reset the I2C if it quite working, basically like a watchdog but different. That seemed to keep it working but it was still a mystery why. Well now I've been playing with I2C a lot more I know it was happening because the I2C was on the limit and required a buffer which would have been the correct fix as the I2C should never quit working.
Well I forgot about all this until about a week ago as for the last year almost I've been loading 4.2 with that reset commented out as I always ran my controller without it and never had an issue. When I did v5 I didn't add it as I figured it shouldn't be needed but looks like a lot of you depend on it as you have these extra I2C devices attached and no buffer so I2C is right on the edge. Before I figured this out some have gotten a buffer and the problem was solved so I will add that back which should get those pH and other Atlas circuits working again.
Now as for v5 alone, it is working not to bad but there does appear to be a possible issues in the schedules, someone discovered if they setup an always on schedule, then deleted it, that outlet couldn't be scheduled again. If more schedules were created after this point it caused all the others to not function any more so maybe stay away from always on schedules till I can look more. I have to get a new computer this week so I can't do anything until then.
Going back to the first issue for Rev-D and before I'm thinking I will add a variable in the sketch to set for users with these boards. However for this to happen I need someone to test as I don't have any old boards. All schedules, custom rules and alerts are also sent in a large chuck of data so it's likely these things won't function properly either and has to be changed to a slower method so that older circuit can keep up.
One possible issue for some of you could be related to controller hardware. Controllers Rev-D and previous have a different circuit for communications between display and controller. With those boards there's a lower limit on the amount of data that can be sent through the serial port at once, if large strings of data is sent there's a good chance it's not all making. Back in the day I tried putting all the sensor data in a single variable so it could all be sent in one chunk but it was too much and it chocked. This is why I had you do that modification to some files in the Arduino IDE, it increased the buffer size for the serial ports, if that wasn't done the buffer would overfill before all data was sent.
On Rev-E controller boards I changed the communication circuit which improved it 10 fold and at that point a lot more data could be sent at once. Now in v5 all sensor data is assembled together and sent in one chuck which is likely too much for the older boards. I had to do that as sensors can now be disabled and sending one piece at a time was too slow for the display to update every second. I know Dom has Rev-D and I'm pretty sure that's why your temp sensors are freezing. Dom can you try disabling all the ports on the hardware connected screen so only one temp sensor is enabled. This will shorted the data to an amount that should be no issue. If you still have v5 installed try that. If you went back to v4.2 it's ok.
I'm not sure about the version of boards others have, I think your ok fietssnrex as I just gave you some updated boards and I don't think I would have given you old ones with the iffy communication circuit.
Now for the other issue which is probably affecting most of you and again seems related to older hardware. Back in the day when Nixu added power monitoring to his power bar he had lots of issues with the I2C hanging. We couldn't figure out why as it was quite random so Nixu found some code that reset the I2C if it quite working, basically like a watchdog but different. That seemed to keep it working but it was still a mystery why. Well now I've been playing with I2C a lot more I know it was happening because the I2C was on the limit and required a buffer which would have been the correct fix as the I2C should never quit working.
Well I forgot about all this until about a week ago as for the last year almost I've been loading 4.2 with that reset commented out as I always ran my controller without it and never had an issue. When I did v5 I didn't add it as I figured it shouldn't be needed but looks like a lot of you depend on it as you have these extra I2C devices attached and no buffer so I2C is right on the edge. Before I figured this out some have gotten a buffer and the problem was solved so I will add that back which should get those pH and other Atlas circuits working again.
Now as for v5 alone, it is working not to bad but there does appear to be a possible issues in the schedules, someone discovered if they setup an always on schedule, then deleted it, that outlet couldn't be scheduled again. If more schedules were created after this point it caused all the others to not function any more so maybe stay away from always on schedules till I can look more. I have to get a new computer this week so I can't do anything until then.
Going back to the first issue for Rev-D and before I'm thinking I will add a variable in the sketch to set for users with these boards. However for this to happen I need someone to test as I don't have any old boards. All schedules, custom rules and alerts are also sent in a large chuck of data so it's likely these things won't function properly either and has to be changed to a slower method so that older circuit can keep up.
![[Image: RTC_traces.jpg]](https://www.robo-tank.ca/pictures/RTC_traces.jpg)