- This topic is empty.
July 14, 2014 at 11:52 am #23055
Could the change of the rain sensor status be logged ? I think even a minute granularity would me more than enough, but I’d love to know when the rain sensor has changed its status. The most important reason is that it could immensely help in setting the “drying window” correctly.
To explain myself an example.
Yesterday morning at 08:00 in the morning I had 11mm of rain with the sensor set to trigger at approx 6mm (1/4 of an inch). The sensor remained triggered until around 13:00 of the day after (so approx 29 hours) with the little “evaporation window” fully open. In this case the soil moisture kept quite high and so the timing is about correct, while in other cases I could have decided to change the evaporation window opening or change the sensitivity from 6mm to more or less.
Thank youJuly 15, 2014 at 5:22 am #27581
One possibility is to create a separate file (e.g. weather.txt) and log the changes in rain sensor status. This should be pretty easy to do. Will try to push this to the next firmware update.July 15, 2014 at 5:24 am #27582
If you log this right in with the other data and use a special index to designate rain sensor it might work better with the mobile app (one less request). We can further discuss if you want.July 15, 2014 at 5:32 am #27583
That’s a good point. Definitely possible to log the data into the same file as the station status.July 15, 2014 at 6:03 am #27584
Sirs that would be great ! And as OS “peripherals” are valves and the sensor, having them into one file with a key specifying the type sounds logical to me.
Thank you very much.July 15, 2014 at 1:27 pm #27585
My older mobile app did this and used the same logging scheme as the stations.
I also logged rain delay periods (to figure out why stations didn’t run etc). Can also be done the same data format just using a special index.
If you use a string instead of int I should be able to type test and get the appropriate names. I figure this is better than a far out int since maybe someone could have a ton of stations on one system.
Thanks!July 15, 2014 at 3:38 pm #27586
I hope I’m not too much of a dumb user 🙂 but in the iOS version of your App I do not see the logs button.
The version of Sprinklers on the App store is 1.1.1 and not 1.2.1 that I see on your web page.
I have an iPhone 4S with iOS 7.1.2 and if I connect to the App store it does not show a newer version.
I therefore cannot access the logs !
I have a 2.1 OS with firmware 2.0.7 and a FAT16 2GB MicroSD.
Thanks for any clarification Samer !July 15, 2014 at 3:49 pm #27587
The logs button on the home page is only hidden if the firmware version is detected as unsupported. Therefore, ensure you are in fact on 2.0.7 and let me know.July 15, 2014 at 6:13 pm #27588
Thank you all is good now.July 15, 2014 at 9:02 pm #27589
along this line for those with concerns on the OSPi – an option to write these specific log entries to rsyslog would be nice. Already have all syslog going to a central syslog server and having already run through corrupt cards on my other RPi due to too many writes trying to cut down on writes is an admirable goal.
Part of me was thinking about process to make the status part of an SNMP MIB with dwell time on a zone/sensor/pin as a pollable value. Currently polling this with MURLIN from a Cacti site and looking for the rain sensor trigger as well as zones in action. Threshold set to alert me if a zone is on for a specific time or sprinkler controller stops responding.July 15, 2014 at 9:59 pm #27590
I completely understand where you are coming from and overall your solution sounds more robust. However, not all user’s will have dedicated syslog servers and typically want the device to work independently hence the focus on SD card logging. I think it should be fairly easy to change the logging method on the OSPi and possibly just add a secondary logging method with an option to switch between either or both solutions.
Side note though, I do have a Cacti server and would love to know if you are willing to share your scripts and templates for logging OpenSprinkler.
Thanks!August 2, 2014 at 2:16 pm #27580
As a Vera (Home Automation) user I’ve seen what happens when too much functionality is pushed into firmware. At some point functionality needs to be pushed out to other devices. So the questions is, most simply, what is appropriate to implement in firmware, and what is should be run other other, hopefully extensible, devices.
What will likely happen is that all the program space is used up on incremental improvements that don’t provide a full solution.October 1, 2014 at 3:46 pm #27591
What about adding the date/time of status change of the rain sensor in the upper red strip ??
Instead of reading “Rain detected”, one should read, say, Rain detected at xx:yy, oct 1, 2014.
I think it would be helpful.
Presently you can only acquire that information only when the results are written in the logs, i.e. when the sensor switch back to the dry condition.October 3, 2014 at 12:57 am #27592
OK, the rain sensed start time already exists in the firmware, so it’s pretty easy to output it to the UI. Will add it to todo list.
- You must be logged in to reply to this topic.