search

OpenSprinkler / OpenSprinkler-Firmware

OpenSprinkler Unified Firmware for OpenSprinkler, OpenSprinkler Pi, and OpenSprinkler Beagle.
http://www.opensprinkler.com
GNU General Public License v3.0
472 stars 283 forks source link

Rain delay - The year is 13592 #233

Closed DomiStyle closed 1 year ago

DomiStyle commented 1 year ago

I recently installed OpenSprinkler with a OSPi board and the year is set to 13592 when enabling the rain delay, any ideas why?

Every other date including timezone seems to be correct.

image

rayshobby commented 1 year ago

I can't reproduce this issue. Do you remember what rain delay duration you set that triggered this to show up?

DomiStyle commented 1 year ago

It happened the very first time I tried setting a rain delay on the OSPi, which was just a simple 1 hour delay. Can't really set any rain delay now without this happening.

Also breaks the Home Assistant integration for OpenSprinkler.

rayshobby commented 1 year ago

I just checked on demo.opensprinkler.com, I can't reproduce this issue. You can set a 1 hour rain delay and it shows the time correctly.

DomiStyle commented 1 year ago

Strange, is there a way to clear the year? Looking at the request it only sends the hour so whatever is going on is stored somewhere?

I just checked the API and the value reported is indeed 366758208803 which equals to the year 13592 so it's not a frontend issue.

rayshobby commented 1 year ago

Can you be more specific? What do you mean by it only sends the hour? Who only sends the hour, to what? Did you mean the UI only sends the hour to the firmware?

DomiStyle commented 1 year ago

Did you mean the UI only sends the hour to the firmware?

Yes. GET /cv?pw=1234&rd=0

rayshobby commented 1 year ago

So setting rd=0 clears the rain delay. As the OpenSprinkler APi document explains: https://openthings.freshdesk.com/support/solutions/articles/5000716363-os-api-documents rd sets the rain delay duration time (the unit is hours). When rd is 0 that clears the rain delay. The firmware uses its current time and add the rain delay time to calculate the rain delay stop time. Does something look wrong here?

DomiStyle commented 1 year ago

Does something look wrong here?

Yes, rdst is always at some absurdly high value, even when no rain delay is active whereas demo.opensprinkler.com returns 0 when no rain delay is active.

edit: devt is correct by the way.

rayshobby commented 1 year ago

rdst is the same as devt, which is an epoch time. Yes it looks very large but that is what epoch time is -- it is the number of seconds since 1970 Jan 1 00:00.

DomiStyle commented 1 year ago

I'm aware, but I do mean absurdly large, way outside of a normal epoch time range:

{
    "devt": 1685986895,
    "nbrd": 1,
    "en": 1,
    "sn1": 1,
    "sn2": 0,
    "rd": 0,
    "rdst": 365072220160,
...
rayshobby commented 1 year ago

Well we are back to my first comment, which is I cannot reproduce this issue. Can you let me know what rain delay time you set to trigger this large number to appear? If I can't reproduce the issue I can't debug it.

DomiStyle commented 1 year ago

Unfortunately I also cannot tell you how to reproduce the issue.

I set the rain delay to 1 hour in the UI right after setting up OpenSprinkler and this is what happened.

rayshobby commented 1 year ago

But I thought you said "Can't really set any rain delay now without this happening." -- which I take as you mean it happens every time you set rain delay to any number.

DomiStyle commented 1 year ago

Correct. So I cannot provide any values to reproduce because it happens every time.

I also just tried restoring a config now where I manually set rdst to 0 but I assume it is not loaded from the config because it's still the same value.

rayshobby commented 1 year ago

OK, can you give me some details: so this is OpenSprinkler firmware installed on RPi, what Raspbian version is it? Is it 32-bit or 64-bit? Is your firmware up to date (either 2.2.0(1), or 2.2.0(2) which we just released yesterday)? Are you using the default OpenSprinkler UI/app, or are you using a third party frontend like Home Assistant?

DomiStyle commented 1 year ago

Sure.

This is a Raspberry Pi 3 Model B with 64-bit Raspberry Pi OS Bullseye installed (Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux).

I just updated to 2.2.0.2 from 2.2.0.1 but the issue persists.

I'm using the regular OpenSprinkler UI right now.

brandan-schmitz commented 1 year ago

I have the same exact setup as described here and I am also seeing this issue. Anytime I set a rain delay no matter the duration it does this. I also see on the forums this was reported 2 months ago and was going to be looked into and nothing ever came of that.

rayshobby commented 1 year ago

How did you compile the firmware under 64-bit Raspbian? If I recall correctly, libmosquitto doesn't have a 64-bit version that's why I was never able to compile it under 64-bit system. I wonder if the issue has to do with that because the firmware was never tested in a 64-bit system. Also, I tried to flash 64-bit Raspbian and it seems my RPi 0 W doesn't support 64-bit Raspbian.

rayshobby commented 1 year ago

I just tested the current firmware on 32-bit bullseye running on my rpi 0 w. Tested with several different rain delay times and all worked fine, I cannot see the issue reported. So I suspect it has to do with 64-bit Raspbian, which unfortunately I cannot test, partly because I don't know how you compiled the firmware for 64-bit since libmosquitto does not work for 64-bit; partly because I don't have an RPi at the moment that supports 64-bit.

DomiStyle commented 1 year ago

Yes, I compiled directly on the Pi using the 64-bit OS with no issues.

libmosquitto doesn't have a 64-bit version that's why I was never able to compile it under 64-bit system.

I don't think that's true anymore:

libmosquitto-dev/stable,now 2.0.11-1 arm64 [installed]
  MQTT version 5.0/3.1.1/3.1 client library, development files

libmosquitto1/stable,now 2.0.11-1 arm64 [installed,automatic]
  MQTT version 5.0/3.1.1/3.1 client library
rayshobby commented 1 year ago

OK, about 64-bit I know what happened. The build script for demo has a -m32 flag: https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/build.sh#L17 what's why when I compile it on 64-bit Linux it says the libmosquitto is incompatible. I removed the flag and was able to compile, and I can NOT reproduce the issue still. I tried 5 different rain delay times, they all show up correctly.

Since I do not have a raspberry Pi that's compatible with 64-bit Raspbian, what's left to do is to find an RPi that I can run 64-bit Raspbian on. That's the only thing I can think of. Without the ability to reproduce the issue I cannot debug.

DomiStyle commented 1 year ago

Did you test on x86? I was able to reproduce it again on an ARM64 Debian VM so you might be correct about this being related to the 64-bit installation.

It's even worse there with the returned number 187648807305929 being out of range in JS:

image

rayshobby commented 1 year ago

Yup, I tested it on my RPi 0 w with 32-bit Raspbian. Cannot reproduce the issue at all. I also tested it on my Linux Mint 64-bit, compiled the demo version, can NOT reproduce the issue.

rayshobby commented 1 year ago

Just to make sure we are on the same page. Here is what I did to compile the firmware on Linux 64-bit: git clone https://github.com/OpenSprinkler/OpenSprinkler-Firmware.git cd OpenSprinkler-Firmware open build.sh and remove the -m32 flag may also have to do apt install gcc-multilib and g++-multilib sudo ./build.sh demo either choose to auto restart, or if not auto restart, manually run the firmware by sudo ./OpenSprinkler open a browser and type in localhost Log in and set rain delay. As I said, I can NOT reproduce the issue.

DomiStyle commented 1 year ago

Yep, that's what I'm doing.

This is in an ARM64 virtual machine though, not on my native x86_64 Fedora PC.

DomiStyle commented 1 year ago

Just to rule out other possible issues I did the same setup with an AMD64 virtual machine and the issue does indeed not happen there.

rayshobby commented 1 year ago

Can you let me know how you installed the ARM64 virtual machine? Lacking an actual RPi that I can use to test ARM64, this would be the best way for me to test. I've tried to install Debian Bullseye ARM64 on VirtualBox but it doesn't work. So let me know how you did the virtual machine.

DomiStyle commented 1 year ago

Sure, I did this on Fedora but it should work in a similar fashion on Linux Mint.

  1. Download Debian for ARM64 from https://cdimage.debian.org/cdimage/release/current/arm64/iso-dvd/
  2. Install virt-manager and its dependencies
  3. Install the ARM and ARM64 cores; the packages on Fedora are called qemu-system-arm and qemu-system-aarch64
  4. Start/Restart libvirtd service
  5. Open the Virtual Machine Manager UI
  6. Create a new VM Select Architecture aarch64 under Architecture options, if it's missing check step 3 again Copy your downloaded Debian image to the path of your default volume (/var/lib/libvirt/images on Fedora) Make sure file permissions of the image are correct Continue through the rest as normally but check Customize configuration before install at the end Make the machine beefy, ARM emulation is slow
  7. Select one of the UEFI aarch64 entries on the firmware
  8. Remove the TPM device on the left
  9. Move your CDROM drive to the front of the boot options
  10. Click Begin installation
  11. Install Debian normally
  12. Boot to Debian after installation
  13. Install git, sudo and build-essential via apt
  14. Install OpenSprinkler without -m32 flag
rayshobby commented 1 year ago

I borrowed an RPi 4 and was able to reproduce the issue and debug it. It turns out the issue was due to the function ultoa giving a different result in arm64 than in all other platforms. Basically this line: https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/opensprinkler_server.h#L59 made the difference. I changed it to use sprintf instead and that fixed the problem. The good thing is that this only affects the display, the firmware variable rd_stop_time itself is correct and so the firmware will stop rain delay at the expected time. The issue just happened when it's converting this variable to string under arm64. In any case, I will commit the changes shortly.

DomiStyle commented 1 year ago

@rayshobby The changes are not in git yet, right?

Jasonkingsmill commented 1 year ago

@rayshobby this appears still an issue - did you want a PR for this?

rayshobby commented 1 year ago

The fix is already in this branch: https://github.com/OpenSprinkler/OpenSprinkler-Firmware/tree/support/os33 will be merged to master soon.

joeracer321 commented 1 year ago

@DomiStyle, did you have success with the os33 branch? Unfortunately I am still seeing the issue on that branch.

rayshobby commented 1 year ago

To make sure you are on 2.2.0(3), at the homepage, swipe left to right to open the side menu, then click 'About'. See if the firmware says 2.2.0(3).

joeracer321 commented 1 year ago

Confirmed I am using 2.2(3). See below: rainDelayError sprinklerFirmwareVersion

rayshobby commented 1 year ago

What RPi do you have and what Raspbian version is it running? I just tried it on my RPi 4 with 64-bit bullseye, I can NOT reproduce this issue.

joeracer321 commented 1 year ago

RPi 3b, 64-bit bullseye.

rayshobby commented 1 year ago

Since RPi 3b has only 1GB memory, is there any benefit for you to run 64-bit bullseye? If you can install 32-bit instead it should solve the problem. What I know is that the problem only happens on 64-bit arm architecture, it does not happen on 32-bit anything, or 64-bit amd architecture.

I will try to get a RPi 3b to see if I can reproduce the issue -- it was quite difficult to get an RPi 4 to test previously. I will ask around to see if I can find a 3b.

joeracer321 commented 1 year ago

Both are ARMV8 instruction set machines, why would it run differently between the two?

psmedley commented 1 year ago

Hi Ray, I have a couple of spare 4GB RPi 4Bs here if you need one. I believe supply is starting to normalise again though Cheers,PaulOn 27 July 2023 06:48, Ray @.***> wrote: Since RPi 3b has only 1GB memory, is there any benefit for you to run 64-bit bullseye? If you can install 32-bit instead it should solve the problem. What I know is that the problem only happens on 64-bit arm architecture, it does not happen on 32-bit or 64-bit amd architecture. I will try to get a RPi 3b to see if I can reproduce the issue -- it was quite difficult to get an RPi 4 to test previously. I will ask around to see if I can find a 3b.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

psmedley commented 1 year ago

Just re-read and see you need a 3B - I can free one up and mail it to you if you need one?Cheers,PaulOn 27 July 2023 06:48, Ray @.***> wrote: Since RPi 3b has only 1GB memory, is there any benefit for you to run 64-bit bullseye? If you can install 32-bit instead it should solve the problem. What I know is that the problem only happens on 64-bit arm architecture, it does not happen on 32-bit or 64-bit amd architecture. I will try to get a RPi 3b to see if I can reproduce the issue -- it was quite difficult to get an RPi 4 to test previously. I will ask around to see if I can find a 3b.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

rayshobby commented 1 year ago

Sure. You can send an email to rayshobbyshop@gmail.com and I can give you my address so you can ship one to me. Are you outside of the US? If so it may not be worth the trouble. I can try to find a 3B at our local makespace, they usually carry some RPis around.

I am also following these instructions: https://github.com/OpenSprinkler/OpenSprinkler-Firmware/issues/233#issuecomment-1582055401 to install arm64 emulator so I can try it without an actual RPi. The installation has taken several hours and I hope it finishes by tomorrow.

rayshobby commented 1 year ago

Can you try again? I just checked in some changes to the support/os33 branch. I was able to install arm64 emulator and debug. I think it is fundamentally due to the fact type long is 4 bytes on 32-bit system and 8 bytes on 64-bit system. Ultimately I need to follow the suggestion here: https://github.com/OpenSprinkler/OpenSprinkler-Firmware/issues/205#issuecomment-1282154396 to use length-specified types line uint8_t, uint32_t. This didn't use to be a problem because the firmware has always run on 32-bit systems. It's till more recently that people have started compiling the firmware on 64-bit system, so we will probably need to fix the integer types.

joeracer321 commented 1 year ago

Can you try again? I just checked in some changes to the support/os33 branch. I was able to install arm64 emulator and debug. I think it is fundamentally due to the fact type long is 4 bytes on 32-bit system and 8 bytes on 64-bit system. Ultimately I need to follow the suggestion here: #205 (comment) to use length-specified types line uint8_t, uint32_t. This didn't use to be a problem because the firmware has always run on 32-bit systems. It's till more recently that people have started compiling the firmware on 64-bit system, so we will probably need to fix the integer types.

@rayshobby , the latest commit resolved the issue on my system. Thank you!

rayshobby commented 1 year ago

OK, good to know. Thanks.

Jasonkingsmill commented 1 year ago

I can confirm this also fixed my issue. Thanks!

cristian-spiescu commented 1 year ago

Great news that this issue is fixed!

However, it's not yet in the master branch, right? Is there an estimate on when it will be shipped in master as well?

CrossEyeORG commented 1 year ago

For what it's worth, I can confirm that the fixes in the support/os33 branch resolved the issue on my Raspberry 4 Model B w/ 8GB (aarch64/arm64 architecture) running Ubuntu Server 22.04. Thanks again.