Time-limited watering

[PerRieland]

What is the best method to avoid watering forever?
I am looking for a method to automatically turn off a coil after an optional amount of time. I use MQTT.
My suggestion is to send a timeout via MQTT in "DataReading.d", so that DataReading.d=0 means off, DataReading.d=xxx means off after xxx seconds. And then build the timer into the controller.
Eg MQTT payload: [{"id": 12601,"type": 0,"data": 180}] to turn off coil no 12601 after 180 seconds.

Looking forward to hearing your suggestions, thanks

[timmbogner]

Hi Per,
I'll try to put together a better example in a few days when I'm home at my computer. In the meantime I'll link you to my FastLED sketch, where I have several different options that can be changed based on the DataReading 'type' of the control message. I use a switch/case setup to do different things with the data.

I'm currently on a small vacation to beautiful
Northern Arizona, USA. It's quite nice!

[PerRieland]

Wauu, how cool is North Arizona ;). Looking fantistic I want to go there
In the meen time I will get some WS2812B and play with your FastLED example.

[timmbogner]

Hey Per,
I really meant that you should look off of the FastLED sketch for reference, but you didn't actually have to get some programmable LEDs, If you did get some, that's good because every maker should try playing around with them at some point!

Upon looking at the Irrigation.ino sketch, I think the best way to accomplish what you want is essentially what you described. Instead of sending "1" as the data to turn on the relay, you would send the number of seconds that you would like it turned on for.

This is a great idea, but I would have to think of a way to implement it into the main example sketch without affecting backwards-compatibility. If changed now, existing users might send "1" expecting it to turn on the relay permanently, but only turn it on for one second instead. Perhaps a negative integer could indicate time. Then "-1" would turn it on for one second, but "1" would still turn it on permanently.

Additionally you will have to set up a system of timers. There are a few libraries that would make this pretty easy, but it's also a great learning experience to do this yourself. You can take a look at this code to see how I made a scheduler for internal gateway functions. It may help to study "function pointers" a bit first. I'll be happy to break that code down a bit if you need help with it. It would confuse me too if I didn't write it.

Another thing of note is that timekeeping will be added within the next couple of months. This will add another level of possibilities, like telling the relay what exact time of day you want it to shut off. I will probably revisit the Irrigation sketch once timekeeping is added, but in the meantime these changes will be up to you!

[aviateur17]

Testing out sketch now to make sure it works as designed. Hopefully will submit PR today.

Unfortunately I wasn't able to use the scheduleFDRS() functionality as it does not include the ability to remove a job from the scheduler. The jobs that are scheduled run perpetually.

Format of loadFDRS....
loadFDRS(data, type, address);

Get Coil status of address 102 (data value is ignored)
loadFDRS(N/A, 1, 102);

Turn off Coil at address 102 for an indefinite amount of time
loadFDRS(0, 0, 102);

Turn on Coil at address 102 for an indefinite amount of time
loadFDRS(1, 0, 102);

Turn on Coil at address 102 for 300 seconds
loadFDRS(300, 0, 102);

When turning on coil for certain amount of time the data value
must be 10 or greater and is in units of seconds.

[aviateur17]

Timm, noticed that addFDRS() only works with ESP-NOW. We should add LoRa functionality to that.

[aviateur17]

Having issues with the Serial -> ESP-NOW gateway not communicating with ESP controller after registration and sending
command. Working through that. If it's helpful I can submit the irrigation sketch I have come up with so far.

Irrigation.ino.txt

[timmbogner]

Timm, noticed that addFDRS() only works with ESP-NOW. We should add LoRa functionality to that.

I believe the reasoning was that LoRa didn't need to do anything in order to receive data from a gateway. It would probably be better to keep them congruent though, you're right.

Took a quick look at the sketch and it looks cool! I see why you added the connection maintenance function (especially for a LoRa system), although it feels a bit superfluous with the gateway timeout maintenance already in the background on ESP-NOW. I wonder if we could combine this into the current one so that LoRa also has some "connection quality assurance". Currently it is dictated by the gateway's #define PEER_TIMEOUT 300000 setting, which is sent to the controller at registration.

I don't quite have time to help test at the moment, but I don't see any glaring issues.

[aviateur17]

Yeah, 5 minutes is a little long to wait to try to reconnect only to see that it may not reconnect and have to wait another 5 minutes. So I tried to speed up the initial connection process. After initial connect that function really doesn't do anything. I was thinking it would be nice to detect issues with the reconnection and speed that up though. Another feature to implement that I will probably forget. I have a running list going in a text document.

Not sure if LoRa is currently configured to register a controller to listen for the callback data. I could be wrong but I don't think it is.

[aviateur17]

PR #205