Update irrigation example to support time limited activation, small c…

[aviateur17]

…hange in scheduler code

Example inject node data in Node Red: Set Address 101 off [{"data":0,"type":0,"id":101}]

Get status of address 102 [{"data":0,"type":1,"id":102}]

Set address 103 on for 20 seconds [{"data":20,"type":0,"id":103}]

Working on multiple array elements but I think some other code needs to be changed before that is supported.

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

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

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

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

Turn on (set) 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.

[timmbogner]

I admit, I sorta forgot about this. I'm finally getting through my springtime work and am looking forward to spending time on FDRS again. I think this looks good, and I'll get to testing it soon!

[timmbogner]

@aviateur17 I was testing this and found an issue in the timekeeping stuff...

There were a couple globals that weren't defined, so it couldn't compile:

 #define GLOBAL_STD_OFFSET     (-5)    
#define GLOBAL_DST_OFFSET     (GLOBAL_STD_OFFSET + 1)

Now I'm getting the following error, presumably due to one of the DST macros needing to be defined. I assume we can just choose one to default to if the user doesn't define it.

In file included from c:\Users\webma\Documents\Arduino\libraries\Farm-Data-Relay-System\src/fdrs_node.h:41,
                 from C:\Users\webma\AppData\Local\Temp\.arduinoIDE-unsaved2024510-7460-1rohzlk.04tz\Irrigation\Irrigation.ino:10:
c:\Users\webma\Documents\Arduino\libraries\Farm-Data-Relay-System\src/fdrs_time.h: In function 'void checkDST()':
c:\Users\webma\Documents\Arduino\libraries\Farm-Data-Relay-System\src/fdrs_time.h:197:10: error: 'tdstBegin' was not declared in this scope; did you mean 'dstBegin'?
  197 |       if(tdstBegin != -1 && (time(NULL) - tdstBegin >= 0) && isDST == false) { // STD -> DST
      |          ^~~~~~~~~
      |          dstBegin

exit status 1

Compilation error: exit status 1

[aviateur17]

Thanks Timm, I'll try to look at this soon.

[aviateur17]

Timm, I'm not sure how changing those defines affects that variable name error.

I think that variable is not defined because neither USDST nor EUDST is defined somewhere.
You can see, in fdrs_time.h, that time_t tdstBegin is defined inside the preceeding macros EUDST or USDST so if neither of those is defined that that tdstBegin variable will not be defined.

So sounds like the issue is that we are missing some #defines in the node_config file.

Now my version of that repo doesn't include the timekeeping stuff so I think when I started that branch the timekeeping stuff was not committed yet. So your testing shouldn't have fdrs_time.h in there. I guess we will need to make sure that node_config.h file is updated with the timekeeping #defines.

[aviateur17]

In main commit this is added to bottom of examples/Controller_Examples/Irrigation/fdrs_node_config.h

// Time settings
#define USDST
// #define EUDST
#define STD_OFFSET      (-6)                // Local standard time offset in hours from UTC - if unsure, check https://time.is
#define DST_OFFSET      (STD_OFFSET + 1)    // Local savings time offset in hours from UTC - if unsure, check https://time.is
#define TIME_PRINTTIME    15     // Time, in minutes, between printing local time to debug

So perhaps seeing if those lines are in your fdrs_node_config.h if your files include the fdrs_time.h file. Again, my repo does not include fdrs_time.h as I think I branched before the timekeeping stuff was committed into main.

[timmbogner]

I should have been a bit more clear. I was testing the new irrigation sketch using the latest version of the main branch of the repo (which includes timekeeping). Timekeeping wasn't added at the time you submitted this PR, thus the node config doesn't have them.

The general issue I have is that most configurations, including these, should have a default value that the system reverts to in case the user omits them. There is currently no entry in 'fdrs_globals.h' for GLOBAL_STD_OFFSET or GLOBAL_DST_OFFSET, and that's the issue there. We should also choose either USDST or EUDST to default to in case neither is set. I'm gonna vote US.

Below is the Single_Channel_Relay sketch, which demonstrates how few configs should actually be needed:

#define READING_ID 31
#define GTWY_MAC 0x01
#define USE_ESPNOW
#define COIL_PIN 5

#include <fdrs_node.h>

bool status = 0;

void fdrs_recv_cb(DataReading theData) {
  status = (bool)theData.d;
}
void setup() {
  beginFDRS();
  if (addFDRS(1000, fdrs_recv_cb))
    subscribeFDRS(READING_ID);
  pinMode(COIL_PIN, OUTPUT);
}
void loop() {
  loopFDRS();
  if (status) digitalWrite(COIL_PIN, HIGH);
  else digitalWrite(COIL_PIN, LOW);
}

[aviateur17]

I understand now. I will submit another PR to cover those #defines in the fdrs_global.h and then the checks at the top of the file to use those globals if user defines are not there.

[aviateur17]

Submitted PR #215 for those timekeeping #defines

[aviateur17]

From the MQTT topic PR #216:

note on: You have the registerWithGateway() function that's essentially doing what already should be done in the background by the ESP-NOW controller's refresh_registration() function. To my knowledge the only device that should need to register are ESP-NOW controllers, since LoRa controllers just process all incoming broadcast packets from their gateway. If this is just an oversight, no problem. If there's something new with LoRa timekeeping requiring more connection maintenance, let me know.

[aviateur17]

You are correct. This is the first time I've played with the controllers receiving values so I just assumed LoRa would need to operate the same as ESP-NOW. But now that you pointed it out I see that there is no "peer registration" required with LoRa like ESP-NOW.

[aviateur17]

Confirmed that multiple commands submitted as one JSON message are acted upon in the controller. My testing is complete.

[timmbogner]

Apologies, it would seem that merging main into here screwed everything up completely. Shoulda just done it locally... I think our best bet is to make a new branch from your last commit, then try again without my recent commit. I was getting it ready to test tomorrow, which I still will do!

[aviateur17]

No Worries.