Forum Replies Created
-
AuthorPosts
-
robiParticipantThere’s a neat Home Assistant integration for OpenSprinkler at https://github.com/vinteo/hass-opensprinkler (also installable via HACS).
robiParticipantGuys from opendata-stuttgart ran into exactly the same issue on their environmental monitoring product which is using the same chip as OpenSprinkler, and managed to resolve the issue:
https://github.com/opendata-stuttgart/sensors-software/issues/729#issuecomment-692966276
robiParticipantFactory reset from the buttons on the unit (according to the manual) + restoring the config fixed the issue.
robiParticipantTicket sent. Thanks.
robiParticipantI made a video about it:
https://youtu.be/1HUUPU7f9L4
robiParticipantI just tested now again.
Unplugged from power, re-plugged it.
1. Yes, the time is correct during the LCD displays ‘NTP syncing’.
2. The time changes to wrong value immediately after NTP syncing.Waited a few minutes. Unplugged from power, re-plugged it. Now it fixed itself:
1. The time is the same as before cutting the power (the wrong value) during the LCD displays ‘NTP syncing’.
2. The time changes to good value immediately after NTP syncing.
robiParticipantAnother idea: what happens if/when OpenSprinkler can connect to the NTP server but can’t connect to opensprinkler weather server during boot?
robiParticipantI was referring to the opensprinkler weather server, which calculates your time zone using your location, which you mentioned before.
The problem flow:
– The NTP is rock solid, and gives UTC time as standard. Verified as being part of pool.ntp.org – it can’t give false time.
– I’m in UTC+2 – that’s based on the calculation from the map, by opensprinkler server
– After NTP sync, time is set to UTC-6 (or UTC-5 can’t remember exactly).
Looks to me as a bug in the firmware somewhere. In the exact moment of time setting the timezone information may be invalid on the unit – that’s what I’m trying to conclude. And that may be different from what’s in the config, because the config export I can make in the browser happens much later than the time calculation happens.
If the timezone info would be accurate in every moment, I don’t see how an UTC-6 would come into the picture. If at boot there’s no timezone info, the unit should default to UTC+0, not UTC-6.
robiParticipantSorry for posting so many times but it looks like this forum engine is enforcing moderation on every post and not allowing me to edit my previous post.
Looks like I’m not the only one who has/had this issue.
robiParticipantAnything changed on server side maybe?
Because suddenly it fixed all by itself.
robiParticipantFyi, I’ve changed the NTP address to 0.0.0.0 but it behaves exactly as before.
robiParticipantAt NTP server IP, I have my own NTP server running from a 1PPS reference signal provided by a GPS receiver. This server is also part of pool.ntp.org.
What do you mean by “the only thing I can think of would be NTP is getting a UTC+0 time for some reason”? All NTP servers always provide UTC+0.
robiParticipantIn my .json file I have
"tz":56
.
The NTP server doesn’t provide any information about the timezone. All time data handled by NTP is in UTC; it’s the local time zone setting which determines the offset from there.For some reason OpenSprinkler doesn’t calculate the correct time based on the timezone.
Is the timezone information avilable at the moment of calculation? Because i’ve noticed that after reboot, the first thing is to do an NTP sync. Maybe during boot the NTP sync and time calculation is done first, and connection to opensprinkler weather server afterwards, thus the determination of the timezone is done after the time has been calculated?Just a tip…
robiParticipantWell, I don’t see any of my updates in the Hungarian language since then, in any of the lately publised app/gui versions.
robiParticipantYep…
And we’ve contributed through that service which is not working anymore… Hard work lost…
robiParticipantUse port numbers higher than 1024.
robiParticipantIt hardly depends on your mobile provider if they allow you or not to do portforwads. Should ask them first.
robiParticipantUnfortunately i don’t see any updates in the language strings i made in the latest app update. Did you forget to pull them in?
June 16, 2019 at 11:00 am in reply to: My Open Sprinkler has been having trouble connecting lately #61093
robiParticipantThese “repeaters” and “range extenders” are very often real truble causers.
Avoid using them.
If you have to, don’t mix manufacturer brands. Also don’t mix new and old WiFi devices (like using an older wifi router and a newer repeater or viceversa) as they may implement standards differently, causing malfunctions.
If there’s no other way to avoid this, use different SSIDs for the main and for the “repeated” signal, so that clients like OS don’t get confused.
But better, try using quality AccessPoints, like Ubiquiti UniFi.
robiParticipantReset to factory defaults…
robiParticipantWhat’s your WiFi channel width? (check in your ap, 20, 40 or 80 MHz?)
How many WiFi aps and routers do you have in your network (specify the type).
robiParticipantI’ve got similar issues.
I think it would simplify a lot if this thing would’t be automated. Just have a manual setting for this. Set it and forget it, since it only has to be done once after unboxing.
robiParticipantGuys, this it offtopic now. This discussion is about rain sensor software delay.
robiParticipantGot it, thanks.
robiParticipantYes, I agree with all the above.
I think filtering out false triggers using a window of 30 seconds would suffice.
-
AuthorPosts