09-27-2021, 01:23 AM
Well today was emotional. 
Didn't get a lot done on software last week, was busy but it was also nice to clear the head of code a little longer. Now I'm ready for a good week on the app.
On Thursday night I happened to notice the dosing reservoirs on app were empty which shouldn't have been. So I hit the refill button and next day they were empty again, oh no!!!!!!! It seemed to be running fine for a few days.
I first thought it was an issue with the custom rules as it was still running the ones in the video. So I dig in, code looks fine sending me in circles then I realize the Pi was sensing a change on the GPIO pin for one of the floats on GPIO 27 so the custom rule was doing what it should have. Each pin is read about 200 per second so I slowed things down, it happened much less but still happened. Then I put controller on bench to see if something is up with the hardware causing a quick LOW HIGH pulse on the GPIO as that's what was happening but on it's own randomly. Sure enough I could see it on the scope.
It was a big change in voltage so I didn't think it could be related to hardware and felt it was more likely something fundamentally wrong with my app but what. I'm using wiringPi library to read and control the GPIO pins, when I started on the Pi I put a good effort into controlling GPIO's directly without a library but wasn't able to figure it out, wasn't as easy as I expected. The original author of wiringPi quit a couple years ago and it seems to be a dead project so I fear one day the Pi would update and it might stop working as it has limited support for Pi 4. I thought it was slim the library was at fault but because it needed changing some point I decided to do another search to control them directly and bam I actually figured it out, now I don't need to be dependent on the library, feeling good about this at least.
Then I setup a sketch to read GPIO 27 directly but I'm unable to, it reports an error saying system is busy. I could read other pins that I randomly tried. So I start searching and come across someone in a forum saying you can't read GPIO 27 directly because it's connected to the LED on the board and something needed to be uninstalled to get direct access to that pin. He also stated pins 0,6,14,15 and 29 couldn't be read directly so I test those and they all read expect 14. Well this didn't make sense as wiringPi has no issues with them and kind of throws a wrench into removing the wiringPi library as nothing I was trying worked.
Because I read that pin is connected to the LED I started thinking the worst, all these controller out there and this is likely happening, the only silver lining I could think was reef-pi isn't monitoring them real time so good chance it would never know that happened as it would be instant, I only discovered this now because I only started monitoring sensors in real time, if a pin changes states within 5 milliseconds the rules will detect it.
So now what, not feeling so great at this moment.
I decided I guess I need to go down the rabbit hole of uninstalling this particle feature the poster briefly mentioned. Eventually I found myself in the config.txt file and what do I see, GPIO 27 and 14 were assigned as a 1-wire bus for DS18B20 temp sensors. I completely forgot I added those Thursday as I was doing one last test one everything for the new controller. I was verifying again the sensor ports would work for them so I had to configure them as such. This is why it was working.
No more issues.
Ah the joys...
For today I'm leaving the wiringPi library, I'll switch over first thing after initial release. All this pain was worth it though, one less library to work with.
Next update should be more exciting.
Didn't get a lot done on software last week, was busy but it was also nice to clear the head of code a little longer. Now I'm ready for a good week on the app.
On Thursday night I happened to notice the dosing reservoirs on app were empty which shouldn't have been. So I hit the refill button and next day they were empty again, oh no!!!!!!! It seemed to be running fine for a few days.
I first thought it was an issue with the custom rules as it was still running the ones in the video. So I dig in, code looks fine sending me in circles then I realize the Pi was sensing a change on the GPIO pin for one of the floats on GPIO 27 so the custom rule was doing what it should have. Each pin is read about 200 per second so I slowed things down, it happened much less but still happened. Then I put controller on bench to see if something is up with the hardware causing a quick LOW HIGH pulse on the GPIO as that's what was happening but on it's own randomly. Sure enough I could see it on the scope.
It was a big change in voltage so I didn't think it could be related to hardware and felt it was more likely something fundamentally wrong with my app but what. I'm using wiringPi library to read and control the GPIO pins, when I started on the Pi I put a good effort into controlling GPIO's directly without a library but wasn't able to figure it out, wasn't as easy as I expected. The original author of wiringPi quit a couple years ago and it seems to be a dead project so I fear one day the Pi would update and it might stop working as it has limited support for Pi 4. I thought it was slim the library was at fault but because it needed changing some point I decided to do another search to control them directly and bam I actually figured it out, now I don't need to be dependent on the library, feeling good about this at least.
Then I setup a sketch to read GPIO 27 directly but I'm unable to, it reports an error saying system is busy. I could read other pins that I randomly tried. So I start searching and come across someone in a forum saying you can't read GPIO 27 directly because it's connected to the LED on the board and something needed to be uninstalled to get direct access to that pin. He also stated pins 0,6,14,15 and 29 couldn't be read directly so I test those and they all read expect 14. Well this didn't make sense as wiringPi has no issues with them and kind of throws a wrench into removing the wiringPi library as nothing I was trying worked.
Because I read that pin is connected to the LED I started thinking the worst, all these controller out there and this is likely happening, the only silver lining I could think was reef-pi isn't monitoring them real time so good chance it would never know that happened as it would be instant, I only discovered this now because I only started monitoring sensors in real time, if a pin changes states within 5 milliseconds the rules will detect it.
So now what, not feeling so great at this moment.
I decided I guess I need to go down the rabbit hole of uninstalling this particle feature the poster briefly mentioned. Eventually I found myself in the config.txt file and what do I see, GPIO 27 and 14 were assigned as a 1-wire bus for DS18B20 temp sensors. I completely forgot I added those Thursday as I was doing one last test one everything for the new controller. I was verifying again the sensor ports would work for them so I had to configure them as such. This is why it was working.
No more issues. Ah the joys...
For today I'm leaving the wiringPi library, I'll switch over first thing after initial release. All this pain was worth it though, one less library to work with.
Next update should be more exciting.
![[-]](https://www.robo-tank.ca/forum/images/collapse.png)
