hunter-wifi

hunter-wifi copied to clipboard

Can anyone confirm whether the STOP command is working? I am able to start zones, but when I try to stop the water keeps flowing and the status returned seems ok. This is a Hunter Pro-C.

i.e.:

curl http://192.168.2.184/api/start/zone/2?time=2 (starts the zone as expected)

curl http://192.168.2.184/api/stop/zone/2

{"status": "Request received and processed correctly." ... }

I use an hunter x-core and stop works just fine for me

https://www.hunterindustries.com/en-metric/irrigation-product/controllers/x-coretm

Also remember that the hunter protocol is a one way communication protocol. Meaning that the message you receive is your esp saying that it received your command and that it sent it out of its pin, but it cannot tell you if the sprinkler got it, nor what the real status is

Thanks for confirming it works for you. With more troubleshooting, I have found that I can start and stop zone 1 as expected, but with any other zones although I can successfully start them (i.e. 2, 3, 4, ... 14), when I try to stop them the controller screen shows "E:RR" . Maybe there is a slight difference in the byte sequence among controllers?

Looking at the HunterRoam.cpp it looks like the stop command does a "startZone" with time=0, so that might narrow the problem to lines 177-182 which use time.

I also have a Hunter Pro-C and the last time I tested it I could successfully stop all zones.

Maybe you could check https://github.com/seb821/OpenSprinkler-Firmware-Hunter to see if they also have this issue.

Thanks for the response. I looked at the seb821 code and found the following comment stating: "Hunter protocol doesn't work on bytes, but on combination of 4, 9 and 12 (not used here) bit numbers."

I am no expert in the protocol ... or any of this :), but looks like there might be a problem with the HunterRoam::startZone constuction... Maybe something can be derived from this approach https://github.com/gashtaan/hunter-xcore-firmware @gashtaan

@bobhavlin the approach you mentioned is my project of alternative firmware for X-Core units, it's completely different than original one.

Though, I have partially reverse engineered original firmware so I have an idea how it works. I commented seb821's code, but seems he didn't notice it.

@gashtaan Thanks for the comment and reverse engineering! I was hoping to use your insight in to the protocol for a fix - Any idea why the stop command here might not work in my case?

@bobhavlin sorry, I have no idea. I don't have any experience with Pro-C units.

X-Core seems to be dumber, it receives the packet from seb821's code OK, but ignores most of it. To start zone on X-Core unit should be enough to send: 11111111/0 10000000/0 ---- 0-------/0 TLTL 1-------/0 THTH 00000000/1 ZZZZ 01111111/

TLTL - time lower nibble THTH - time upper nibble ZZZZ - zone number bits marked '-' are ignored

Note, that this is just a theory... I looked at the code, but never used it or tested it.

@gashtaan Thank you for your input. Although I am an engineer, I do not have an extensive background in electronics.

According to seb821's code, he supports up to 48 stations. However, from your packet I can see than only 16 are supported. I guess this is a difference between X-Core and Pro-C.

@ecodina yes, I am aware of this difference, X-Core supports only up to 8 stations at hardware level, so 4 bits in the packet are enough.

Just wanted to point out that X-Core actually parse different part of the packet, so I can't help with Pro-C devices. Maybe there is some compatibility between them and Pro-C understands the simpler packet for stations 1-16, but I'm afraid command number (00000000/1) in the packet does matter and I don't know it.