Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Save problems with Timers and SetPoints

edited December 2014 in Development
Hi folks. I have been on the sidebar of this project for quite some time. I have my almost Fully working yieldbuddy. Thanks Yildbuddy and the community. 
I have done my own mods and got it to a point were it pretty much does what I would like it to do.

But I do have a problem:
When I set the times for the lights or watering schedule it saves for a certain period of time then reverts back to the original code. If I change and do a power cycle it reverts back once back up. Any ideas, what am I missing. 

Thanks Folks.

Comments

  • It must not be saving into the EEPROM successfully.  It's loading the values from EEPROM with the EEPROM.read() function in yieldbuddy_arduino.ino.  It must be getting reset somehow.

    There's a better way to save the data, like on an SD card or something, so I'll be looking into this after my finals are done.  I'd also like to port everything to C++ and bring all of the scattered files into one easier to navigate project.  What a mess! 

    I can see under Serial_functions.ino: 

            EEPROM.write(76, Light_ON_hour);
            EEPROM.write(77, Light_OFF_hour);
            EEPROM.write(209, Light_ON_min);
            EEPROM.write(210, Light_OFF_min);

    and for yieldbuddy_arduino.ino:

      Light_ON_hour = EEPROM.read(76);
      Light_ON_min = EEPROM.read(209);
      Light_OFF_hour = EEPROM.read(77);
      Light_OFF_min = EEPROM.read(210);

    So it looks like they're corresponding to the correct addresses. 

    Try setting the light schedule and sending a blank command (like a space ' ') on the System page.  I'm thinking maybe that the command file isn't being flushed out?
  • Thanks for the reply yeilbuddy and hope your finals go great!!!

    I have tried sending the command as you have said but same thing happens. Plus I forgot to mention that it generally takes 2-3 send commands for the change to take place on timers and setpoints. 

    I am also debugging on my side and if I come up with the problem I will share.

    On a different note on one of the discussions you folks were talking about a memory leak. I have been able to figure that out. When a wired network eth0 is not plugged in after 30 min to 3 hours memory usage climbs to 100% and then swap climbs to 100% thus almost unresponsive pi. I have narrowed down the culprit to the test_network script. The script just forces eth0 and dhclient. 

    I am testing the script a bit different and will share results. 
  • Makes sense.  I guess while testing my goal was to keep up the network comm's as much as possible, forgetting to test taking comm's down numerous times.
  • @nevsen - Did you get your script working? I'm seeing the same lockups. I would be curious to see how you resolved the issue.
  • I'm experiencing the similar save problems, and would like to see the SD card option in place of EPROM for the benefit of saving the EPROM from excessive writes, something that happens twice everytime the arduino is hooked up to power or reset with the current code... First to zero out and then to write defaults. Not a great thing for the longevity of the EPROM.

    This sketch is rather large, and I believe a bit more abstraction could get this down to the size it could run on an Uno, or more ideally with the Raspberry pi's serial hooked up through logic level converter or voltage divider to a 328p acting as master on an I2C bus with module slaves running lighter and more efficient code for sensor values. Possibly even use a shift register to drive the relays. I2C from the master to SD card could hold sensor readings, should the pi hang or reset, and with the help of a switch case block, incoming serial statements from the pi can be appropriately routed to update set points and request readings from auxiliary modules.

    Currently, the arduino is quite chatty to the point of being too verbose and it seems the 115200 baud gets the raspberry pi a bit stressed out, especially with the memory leak caused in the test_network.py *(any working code on this front for including wlan0 as a valid network connection?)

    There are a multitude of reasons to get this off the Mega and slim down some of the code. I see no reason the Arduino needs to use so many variables, especially floats and strings, when multiplication can reduce the size of a float to an int and the arduino doesn't need to be speaking in terms of "OK" when a boolean will suffice. Tokenizing the incoming serial string and using the same structure to update/request based on switch/case blocks makes a lot more sense as far as space considerations go. The yieldbuddy python script would need to have a similar schema for dealing with incoming serial strings which doesn't seem that difficult.

    I've got some code I can dig out of my private repo that may be helpful here, though I was using Java and JDBC connection to MySQL, so some adaptation will be my work for the weekend.

  • I agree with everything you've said here.  There's definitely some improvement to be done.  I have no choice but to pick up the slack on this and start getting motivated - Spring cleaning time.
  • I'm having the same eeprom resetting problem.  Has anyone solved this?  To me it looks like it is not saving to the eeprom properly, and just using the memory settings.  I'm hoping someone has solved this, as its one of my last steps.

    I would have to disagree with marc's assessment.  I like the fact that the arduino could work independently of the raspberry pi.  It gives a degree of failsafe, where as, if the raspberry pi halts, the arduino could continue functioning. I'm thinking that if the settings are saved on the SD card of the raspberry pi, the arduino, won't have the values to continue working.

    also, I have it currently working without the logic converter, straight through USB. I find this much smoother and does not rely on another piece of hardware that could potentially fail.

    p.s.  the memory leaks have been fixed on my end, its a few errors that could found inside the /var/log/nginx/error.log and also test_network.sh script (mentioned above).

    Any help with the EEPROM reset problem would be greatly appreciated.
  • I think he meant a SD card with the Arduino, which would work nicely.   Any big changes with that you made in regards to the memory leaks?
  • agr
    edited June 2015
    ahh, that would make sense.

    for the nginx errors, I had to basically upgrade the php pages.  should i upload it to github?

    any luck with the EEPROM reset problem? I can't seem to find a solution to this one.
Sign In or Register to comment.