Felix,
I would have to look back thru my logs but I just noticed a couple weird things started happening while running the sprinkler program below.
MN : { states: [{ label:'Run z4-14', action:'PRG 4:900 5:1800 6:1800 7:900 8:1800 9:1800 10:1800 11:1800 12:1800 13:1800 14:1800'}]},
When zone 8 finishes the 30 minute runtime zone 9 starts but on the dashboard it still shows zone 8 running. The timer for zone 8 runs for 1 hour then it changes to zone 10 which runs for 30 minutes.
also;
After zone 11 runs for 30 minutes the program shuts off before running zones 12 thru 14.
So I started over and changed the program to run each zone for 30 seconds to see what happens.
MN : { states: [{ label:'Run z4-14', action:'PRG 4:30 5:30 6:30 7:30 8:30 9:30 10:30 11:30 12:30 13:30 14:30'}]},
Now it shuts off after running zone 13 and never runs zone 14.
Any help as to where the problem might be would be appreciated,
Thanks
Just looking at your note, not knowing anything about the code executing, it appears that the string length where the failure occurs is approximately the same...
At first glance the action is too long: "PRG 4:900 5:1800 6:1800 7:900 8:1800 9:1800 10:1800 11:1800 12:1800 13:1800 14:1800" is 84 chars.
The second one "PRG 4:30 5:30 6:30 7:30 8:30 9:30 10:30 11:30 12:30 13:30 14:30" is 64 chars.
This "action" will be sent as a packet to the node, so it will be truncated since the radio supports up to 61 bytes. Do you really have 14 stations? Maybe try to shorten those by using HEX (A=10 .. F=16), if they are all multiple of 900 then use that as a special 1 letter unit perhaps, those are just a few suggestions, there could be many ways to encode such a long message into a shorter one. That would of course require changing the sprinkler node code to recognize those changes.
Or if you want this simpler, just schedule 2 separate programs that run back to back, to fit the longer message in 2 split shorter messages.
I appreciate both responses.
Yes, 14 zones (big yard) So do you have any of your RFM69 examples using the HEX example you mentioned?
Thanks
Also, why would this cause the first issue I mentioned being as though zone 8 was before the 61 character length limit was reached?
When zone 8 finishes the 30 minute runtime zone 9 starts but on the dashboard it still shows zone 8 running. The timer for zone 8 runs for 1 hour then it changes to zone 10 which runs for 30 minutes
I do not have another example for the IOShield, only the one published.
RE your question, see this line (https://github.com/LowPowerLab/RaspberryPi-Gateway/blob/master/gateway.js#L142) where the serial write to your gateway node happens.
serial.write(node.nodeId + ':' + node.action + '\n', function () { serial.drain(); });
Depending what code your gateway is running, that buffer which captures that action might also truncate it.
Thank you Tom and Felix for your responses. I will experiment with it and see what I can come up with.
PRG 4:900 5:1800 6:1800 7:900 8:1800 9:1800 10:1800 11:1800 12:1800 13:1800 14:1800
could become
PRG 4:9 5:18 6:18 7:9 8:18 9:18 10:18 11:18 12:18 13:18 14:18
could become
4,7:9 5,6,8,9,10,11,12,13,14:18
could become
4,7:9|5,6,8-14:18
could become
4,7:9|5,6,8-D:18 = 16 characters
There is no reason to pass human-readable strings other than ease of debugging maybe. I'm sure others could find a way to compact the information more but this is already a 7x reduction over the original and probably would suffice for you. If you didn't want to give up single second precision (which surely isn't needed in an irrigation control most get by with minute precision) you could pass seconds as hex like:
4,7:384|5,6,8-D:708 =19 characters
You just have to make sure whatever encoding you implement on the Tx node the Rx node knows how to undo it. In the above case since so many zones end up having the same run time, you could represent the zones vastly more efficiently as 16-bit numbers so zones 4 and 7 in a 14 zone system is sent as: 0001 0010 0000 0000 = 0x1200 and 5,6,8-D as: 0000 1101 1111 1100 = 0xDCF so the message could look like
1200:384|DCF:708 = 16 characters
using the first hex value in the pair to represent 16 flags (16 zones) and the second hex value to hold the seconds of runtime for those zones.
By the way, it is generally better with turf to split a 30 minute water application up into 4 7.5 minute deliveries and spread them 30 minutes apart. That gives the grass time to soak up some of what is delivered rather than applying it so fast that it runs deeper than the root zone. I have short zone times but the program runs 4 times at 3:00AM, 4:00AM, 5:00AM, and 6:00AM so that water doesn't sit on the grass overnight but all the watering is done before the sun comes up (much) and the wind speeds evaporation.
Well as most here know, if not all :P, I'm very new to this type of programming but you gave me a lot to work with. I really appreciate your time and suggestions.