Forum Replies Created
-
Posts
-
Blank page usually happens when the result from the controller is malformed. To check, you can open a browser and type in the following and check the result:
http://x.x.x.x/ja?pw=a6d82bced638de3def1e9bbb4983225c
where x.x.x.x is your controller’s IP address, /ja is a command that requests all json data as a whole, and a6d82bced638de3def1e9bbb4983225c is the md5hash of ‘opendoor’. As you said, after upgrade, the device key will reset back to opendoor, so this should work. The result should be a valid JSON string (you can use any online json parser to check if the result is valid or not, such as: http://json.parser.online.fr/Perhaps you can perform a factory reset just to make sure all parameters are reset back to default values.
Click button B1 to find out the IP address. It’s possible that the IP address has changed after you upgrade the firmware.
Maybe use a multimeter to check the voltage between 5V and GND first? Note that that 5V is derived from OSPi, so depending on how much current the fan draws, it may exceed the capability of OSPi’s 5V output current. In that case you should additionally plug in a microUSB cable (connected to a USB charger) to RPi. This will provide additional power to the 5V line.
This is because by default all zones are “sequential” — both programs will be scheduled at the same time, but since zones are serialized, they will run one after another. This is not because of programs are put one after another, rather, it’s a zone property.
“could not find USBtiny device (0x1781/0xc9f)”
means it’s missing a driver. You can download and install the driver available here:
https://learn.adafruit.com/usbtinyisp/driversIf you are using firmware 2.1.9, please note that ‘rs’ has been removed and replaced by sn1. The reason is that this firmware supports 2 independent sensors for OS 3, and each sensor can be independently configured as different types of sensors, so in order to make it more general, we no longer call it ‘rs’ (rain sensor) but replaced it with sn1 (sensor 1).
It’s not for protecting the circuit from 24V, rather, in earlier versions of the circuit design, I used 5V on 74HC595, and so the resistor is there to be a current limiter between 5V and 3.3V. It didn’t turn out to be necessary, but I kept the resistors anyways.
Yes, I’ve looked at SSRs for driver. They used to be quite expensive. Now they are cheaper, so it’s certainly feasible. One thing you may want to look at is the maximum current they can drive. Some of them are quite low, like below 500mA, which would be an issue if someone wants to plug in two solenoids into one port.
Maybe it’s called avrdude_win? You can do
dir *.exe
to find what’s the exact name of the executable.0x2D means SD card issue. This error is shown when the controller reboots and couldn’t detect the SD card, or detect an error in the SD card.
Look, I think some of the issues you are seeing may be inter-related. I’ve already mentioned in another thread that perhaps try to reduce the number of zones. In fact, why not perform a factory reset, and keep it in that state (do not import configurations) and monitor it for a while. If the symptoms are gone, that gives us some knowledge about what could have gone wrong (as I said, possibly a data buffer corruption issue due to large data transfer). If you don’t test it in the factory reset state, that won’t help isolate the problem and the result is a bunch of problems stacking together and we don’t know the root cause.
The resistors act as current limiters: in the event of damage to 74HC595, they reduce the chance of the damage to RPi.
The video instructions are obsolete. Since we haven’t updated the firmware updater for a few years, it no longer runs on many operating systems. Instead, just use avrdude and follow the command line instructions. (The updater is simply a GUI for the same command line instructions).
We no longer provide the pre-configured SD card image. Instead, just install operating system on your beaglebone, and follow instructions here to install and run firmware:
https://openthings.freshdesk.com/support/solutions/articles/5000631599-installing-and-updating-the-unified-firmware-on-ospiThere is no need to delete any zone information: you can just go to Edit Options -> Station Handling, and set the number of zones to a smaller number, like 8 or 16. Then reboot so the controller starts from fresh. The previous zone information is still preserved, so in the future when you change the number of zones back, the zone name, programs etc. are still there, they are not lost.
The reason to try this experiment is to check whether something is corrupting the Ethernet buffer, which may cause the weird NTP sync problem. One such possibility would be if you have a large number of zones or programs, as soon as you access the controller, transferring that amount of data from the controller to the app / UI may trigger the corruption. So by capping the number of zones, it allows us to tell if this might be the root cause of the problem.
Firmware 2.1.9 uses a different library and mechanism to handle Ethernet connections, so it’s possible this is a new bug that wasn’t in previous firmwares.
Given that you have a large number of zones and programs, to isolate the possible causes of the problem, I suggest that you temporarily set the number of zones to a smaller one (like 16), and reboot, and see if this makes any difference. I personally can’t reproduce the issue you are seeing — I’ve imported your configurations on a test OS 2.3 and I don’t see any NTP or timing issue. But I wonder if the problem maybe due to the rather large number of zones and programs, such that when accessing the controller, transferring this amount of data is triggering some buffer overflow problem that we haven’t discovered, and that in turn affects NTP. The easiest way to test is to make the number of zones smaller, so that when you access the controller, the data remains small. At least this is worth a try since I otherwise have no clue why this is happening.
The weather call is made every 2 hours:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L58Regarding the error ‘Building Weather History”, I just became aware of the weather call error: this has to do with the daylight savings time change yesterday. Apparently our current script has a bug that if DST is not accounted for, then the next day it returns an error that it didn’t get sufficient 24-hour weather data from yesterday. This should resolve itself by midnight today once we are outside of the 24-hour window. but obviously we will fix it so it doesn’t happen again next year.
Then this must have to do with the browser you are using — I just looked at demo.opensprinkler.com and it looks fine. When I change location, the map pops up just fine.
If you use OSPi: this option is not available because for RPi NTP is managed by Raspbian, the firmware does not manage NTP at all.
I suggest that after a reboot (after it gets correct time), you turn off NTP (in the Settings page -> Advanced, you can turn off NTP). Monitor it for a few days and see what happens.
You are correct that the sensor input is only used to trigger the start of a program, not to stop it. In fact, the way it works is that when the sensor input is activated, it stops whatever is running currently, and runs the designated program. So let’s say you activate the sensor input, that runs the second program, then you activate it again, that will stop the second program but then immediately start it over again.
The buttons on the controller can be used to stop any running program, but as you said, your controller is inside a box so you don’t have access to the button.
Your 555 timer solution is very clever. Kudos for that.
It’s possible (if you don’t mind soldering) to solder two wires onto the controller’s button (I have to double check the user manual, but I think B1 or B2 is used to stop all running zones when you long press it), then you will have access to that functionality outside of the box. We can also modify the firmware to add a logic where if the sensor input is activated, and that program is already running, we stop it instead of start it.
Here is my suggestion to start the diagnosis: at 10am, look at the homepage in either the mobile app or web UI, or look at the LCD, does it show that the scheduled zone is running? If so, that means the software has turned it on successfully, so the issue is in hardware, it could be a problem with the controller or your sprinkler valve. If at 10am, you don’t see the zone running on the homepage, or LCD, that means it’s a firmware issue — the software didn’t even attempt to turn it on. This will help decide what’s the next step.
