Forum Replies Created
-
Posts
-
Can you submit a support ticket? We can arrange to send you a replacement so you can check and compare with your current one.
If I understand it correctly: the LED lights up and fades out every time you connect the power? What happens when you remove the RPi and just apply power on the OSPi board (without RPi)? Does the LED do the same thing?
OK, sounds good. If you want to wait till next firmware update, you don’t have to update right now. Keeping it in static IP should avoid the DHCP burst as you already know.
The last update as you can see:
https://github.com/OpenSprinkler/OpenSprinklerGen2/commit/3f32a564e278f32ebfd3aae7efa15769f10e83f2
is 12 days ago, which means most likely you have the previous version, so an update is highly recommended.When LCD shows ‘Connecting…’ it IS making a DHCP request and waiting for response to come back. So as I said, if for some reason, the bug was triggered and the controller gets stuck in the connecting loop, that can well explain the DHCP burst.
If you want to try, you can set the controller in static IP, which should bypass the DHCP burst.
Hmm, this is definitely strange, because it’s not only ‘last successful weather call’ is falling behind, but also ‘last weather call’ is falling behind. This means the firmware is not even making the requests.
Looking through the code (https://github.com/OpenSprinkler/OpenSprinklerGen2/blob/master/main.cpp#L579), there are a few conditions where the controller would not send the weather call:
1) a program is running currently (but no program can run for longer than 18 hours, so this is unlikely the condition).
2) the last successfully received weather call is more than 24 hours ago, in which case it will trigger a network re-connection instead of making further weather calls. I just realized this is actually a bug, since once this condition happens, it will never make a weather call again. However, for this to happen in the first place, the controller has not successfully received any weather call (which was sent every 30 minutes) for 24 hours, and this is certainly an unusual situation. In any case, this is definitely a bug that should be fixed.For now I suggest you restart RPi or at last restart the firmware.
@DaveC: this is the first time I heard about the DHCP burst issue. I suspect it’s an issue with the EtherCard library that OpenSprinkler firmware is built on. I will use WireShark to monitor the web traffic and see if I can reproduce the issue.
Before we proceed, which firmware do you have? If you don’t have the latest firmware 2.1.4, I suggest that you upgrade to firmware 2.1.4 because it contains several Ethernet related bug fixes that may have fixed the issue. Even if your controller already shows firmware 2.1.4. I still recommend you to re-flash, because there was a silent update to 2.1.4 firmware a couple of weeks ago that wasn’t announced. In retrospect we should have numbered it 2.1.5 but the changes were too small to make it 2.1.5. Make sure you click on ‘Download Firmware’ before updating, so you can grab the latest files.
To be more specific, these are the most recent changes:
https://github.com/OpenSprinkler/OpenSprinklerGen2/commit/3f32a564e278f32ebfd3aae7efa15769f10e83f2
there is a bug with the way timeout is calculated and in some cases that could cause the controller to get stuck in the ‘Connecting…’ loop for a while. I should have brought this up earlier, but I am not 100% optimistic that this completely solves the issue. So I suggest updating the firmware and let me know if the issue still persists.@catalin: the firmware uses increasingly longer timeout to perform re-connection. Specifically, if ping tests failed N times in a roll, it waits for 2^N minutes before re-connecting. There is no TCP resource to free or anything: it uses a statically allocated buffer, and there is no dynamically allocated memory.
Can you clarify if it’s the ‘last weather call’ or ‘last successful weather call’? The ‘last weather call’ indicates when the controller sends out the request, and ‘successful weather call’ indicates when it received the weather data.
The instructions from Firmware 2.1.4 announcement is more recent:
https://opensprinkler.com/forums/topic/announcing-opensprinkler-unified-firmware-2-1-4/
basically the same with instructions on the 2.1.3 announcement post as you linked to.DS3231 and DS1307 are functionally the same, except that DS3231 has a built-in temperature compensated crystal, which makes it more accurate, but also the chip is much larger. They both use the same I2C address and libraries that work for DS1307 should work for DS3231 too.
By the way, about the ‘Connecting…’ message, that means the controller cannot ping the router — the firmware is set to ping the router every few minutes to check if it’s still connected. If the ping requests fails several times in a roll, it will restart the Ethernet controller. So frequent ‘Connecting…’ means it’s not able to reach the router for some reason.
If anyone can run WireShark could you monitor the network traffic for a while? That may help find out the issue.
Because OpenSprinkler runs a microcontroller-based embedded server, it’s not as fast and robust as a Linux box. Especially if it’s performing other web tasks (like it periodically pings the router to see if it’s still connected), it can’t respond to incoming requests. That could explain why the ping sometimes works and sometimes doesn’t. Also, it periodically send requests to the cloud server, so that will temporarily block the incoming requests too. The firmware does check the connection and when it decides that it has lost connection it will re-start the Ethernet controller. In any case, all I am saying is that it’s a much weaker server than a Linux box.
Because it’s a big investment to make a new enclosure, we don’t have immediate plan to make a dedicate enclosure for OSPi.
Instead, I am trying to finalize the design of the OSPi 1.5 A+: a special version for RPi A+ which will have an LCD and buttons just like the microcontroller-based OpenSprinkler. This way it will fully use the current enclosure. For details, check this blog post:
http://rayshobby.net/work-in-progress-opensprinkler-pi-ospi-a-will-finally-close-the-gap/OSBee Arduino shield is currently only available at Rayshobby Shop:
http://rayshobby.net/cart/osbeeshieldSorry about the delay. I’ve just updated the OSPi pre-configured SD card image today (it now supports RPi 2 as well), and also updated the user manual. The user manual is in the same location as before:
http://rayshobby.net/docs/ospi14_manual.pdf
and the image link is in the manual.Due to the increasing number of reported issues with the WiFi adapter, we are now recommending powerline adapters:
https://opensprinkler.com/product/powerline-ethernet-adapter/
which is more reliable than WiFi adapters.Well, just a slight correction: the Zimmerman method calculation is actually done on the cloud server — OS receives a simple ‘watering percentage’ parameter from the cloud server. We are working on allowing the user to edit certain parameters and this is likely to be available in the next firmware update 2.1.5. The idea is to save user parameters on the OS side, and it will pass the parameters to the cloud server when it’s making the weather call. However, the calculation will still be done on the server side, partly to release OS from having to carry out this calculation, partly because this streamlines the handling of weather algorithms, allowing people to use new weather algorithms without firmware update.
First of all, you can change the port number by going to ‘Edit Options’ -> ‘Advanced’ -> ‘HTTP Port’.
Second, before you do so, please note that you should NOT set port forwarding on your tp-link adapter (in client mode) — the tp-link adapter serves as a simple pass-through and it transparent (imagine it as a wired connection except it goes wireless). The port forwarding should be set on your main router (i.e. the router connected to your cable modem).
I am pretty sure this Gardena valve is a latching solenoid valve, so it’s NOT compatible with OSPi. I can tell it because the document says the 9V valve is to be used with control unit 1250, which is a battery powered controller. Only latching solenoid valves can work with battery powered controller, 24VAC valves cannot work with battery powered controller.
The buttons only support one ’emergency stop’ function, the same as ‘stop all zones’ function. When a station is running, press and hold B1 will stop all stations immediately.
Other places to look for are security camera stores — classic security cameras use 24V AC power supply. Also, many HVAC systems, and even door bell circuit sometimes use 24V AC.
Sure, what you described is the ‘inrush current’, which is typically 2-3 times the holding current. Still, that shouldn’t have burned out the RPi.
Do you have a link to your 9V valve? I’ve seen several 9V valves that are latching solenoid valves. These cannot be used with OpenSprinkler Pi because the control mechanism for latching solenoids is different.
