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
4 Comments
Max Cai posted 10 days ago Admin
Hello Anastasakis,
I looked into this further,
Using your example, the current time is 13:25 (UTC+2+1), but the time read by the Toolbox is 12:25 (UTC+2).
It's important to note that, for the device, its time is indeed 12:25 (UTC+2).
When the Toolbox attempts to synchronize the time or write a configuration that includes a time—such as when configuring a schedule—the time sent to the device by the Toolbox will not include DST.
In other words, when a schedule is configured in the Toolbox to run at 12:25, the time actually sent to the device is 11:25. Since the device's time is 12:25 at that moment, the schedule will not execute.
However, if the time configured in the Toolbox is 13:25, the time sent to the device is 12:25. In this case, the device will execute the scheduled task.
For now, we would recommend that you temporarily configure these commands based on the actual time so that the device can execute them as expected.
Have a nice day.
Best Regards,
Max Cai | Technical Specialist
0 Votes
Anastasakis Ioannis posted 15 days ago
Hello,
I am reading the UC512 using the toolbox. The time that the UC512 displays now is 12:21 . The rule says open valve 1 at 12:25. At 12:25 (UC512 display time) the valve does not open.
When I set 13:25 ( Athens time, UTC+2 + 1 hour DST that is also the time the UG65 reports) then the valve opens.
My conclusion, UC512 sync with the UC65 that is considering also the DST.
The time that the UC512 displays is wrong but the time that the commands apply respect the UG65 time that is set to timezone 2 Athens and sync with NTP server and that is +1 hour in this time period.
So if you do not look at the time that the UC512 says, and you send your rules based on the ntp server time then there is no problem.
0 Votes
Max Cai posted 15 days 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 15 days 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