We use cookies to try and give you a better experience in Freshdesk.
You can learn more about what kind of cookies we use, why, and how from our Privacy policy. If you hate cookies, or are just on a diet, you can disable them altogether too. Just note that the Freshdesk service is pretty big on some cookies (we love the choco-chip ones), and some portions of Freshdesk may not work properly if you disable cookies.
We’ll also assume you agree to the way we use cookies and are ok with it as described in our Privacy policy, unless you choose to disable them altogether through your browser.
Hello,
I am currently developing a large-scale irrigation project using a UG65 Gateway and 17 UC512 Solenoid Valve Controllers (Firmware v1.7, HW V4.0).
We have successfully implemented the downlink logic via Node-RED to push schedule templates. However, we are facing a critical issue: The rules are stored and enabled in the controller memory (verified via NFC ToolBox), but the controller does not trigger the valve at the scheduled time.
Our Technical Environment & Findings:
Command Format: We are sending a 30-byte hex payload to fPort 85 using the 0xFF55 command.
Verification: When we "Read" the controller via NFC ToolBox, the rules appear exactly as intended:
Rule ID: Correct and Enabled.
Validity Period: Correct (e.g., July 1st to July 30th).
Start Time: Matches the controller's internal clock (verified UTC/Local offset).
Loop Period/Interval: Correct (e.g., Every 1 Day or Weekly Bitmask).
Action: Valve 1/2 Open, Duration 3600s, Time Control Enabled.
Time Sync: The UC512 is synchronized with the Gateway. We have tested future-dated start times (to avoid missing the "Start Edge"), but the valves still do not fire.
Payload Comparison: We exported the JSON from a manually created (working) rule and compared it to our downlink-generated rule. The binary structures (30 bytes) appear identical.
The Problem:
Even with the rules stored and the time correctly aligned, the device remains idle. It does not update its internal valve status to "Open," and it does not send a status uplink when the watering should begin.
Questions:
Is there an undocumented "Work Mode" bit or a "Control Mode" command (e.g., Manual vs. Timing) that must be toggled via downlink before the hardware will respect the stored 0xFF55 rules?
Does the UC512 require a specific Time Sync acknowledgment or a "System Commit" command after rules are written to move them from the radio buffer to the execution layer?
In Firmware v1.7, are there specific requirements for Byte 11 (Loop Period) and Bytes 12-13 (Interval) that differ from the standard documentation? (We are currently using 01 01 00 for Daily and 02 Mask 00 for Weekly).
Example Payload Sent:
ff550101016808436a0c43696a0101010002010101840300000000000000
Any guidance on why a "Verified" rule would fail to execute would be greatly appreciated.
Best regards
Gianni
Triton SA
0 Votes
2 Comments
Max Cai posted about 11 hours ago Admin
Hello Anastasakis,
May I know have you tried using Toolbox to synchronize the device time? And have you checked for time discrepancies using Toolbox?
It appears that the device did not open the valve at the expected time due to a time zone discrepancy.
Have a nice day.
Best Regards,
Max Cai | Technical Specialist
0 Votes
Anastasakis Ioannis posted 1 day ago
I created a time rule (using the windows toolbox) that opens a valve at 08:00 (that is UTC+2 + DST) and the valve opened even if the time reported by the toolbox was 07:00.
So after removing the DST correction, that I was applying in my code before sending the rules, the rules are no respected and the valves open as expected.
0 Votes
Login or Sign up to post a comment