UC511 mqtt command syntax?

Posted 2 months ago by Chiara Tecnoelettrica

Post a topic

Solved

Chiara Tecnoelettrica

Dear Sirs,

got a UG56 that correctly receive status update and send trough mqtt.

This is what I've tried so far:

mosquitto_pub -h broker -t "ug/downlink" -m '{
"devEui":"devicetoOPEN",
"confirmed":true,
"fPort":85,
"data":"ff1d2000"
}'
mosquitto_pub -h broker -t "ug/downlink" -m '{
"devEui":"devicetoCLOSE",
"confirmed":true,
"fPort":85,
"data":"ff1d0001"
}'

can see on another subscription terminal

ug/downlink {
"devEui":"device",
"confirmed":true,
"fPort":85,
"data":"ff1d2000"
}

but in network server nothing seems to be received

Instead if I send data to device directly from that page a greyed out row is added .

But no message is published on mqtt when data is sent from th web page ug/uplinkdata. I receive:

{"applicationID":1,"battery":100,"devEUI":"device","deviceName":"YV01","gatewayTime":"2026-05-16T11:09:10+02:00","gpio_1":1,"gpio_2":1,"valve_1":1,"valve_2":0}

I need to trigger also commands:

- disable/enable time schedule

- direct command

- change time schedule

Actually device are programmed via NFC.

Can you please tell me how to do it correclty?

Thanks, BR

0 Votes

7 Comments

Chiara posted 7 days ago

Dear Aslan,

thank you for your reply, no worries about the delayed response.

I have now upgraded the UC511 to firmware version 1.7. After repeating Test 1, I can confirm that it completed successfully.

I hope the test script I developed during the troubleshooting process may also be useful for helping other users or for future testing.

I prefer using the built-in timer on the UC511 rather than sending separate Open and Close commands, as I believe it is a safer and more reliable approach for irrigation control.

Thank you for your support, have a nice day!

Best regards

0 Votes

Aslan Lu posted 11 days ago Admin

Hi Chiara,

Thanks for your reply.

Sorry for this late response.

Could you please check and share with us the firmware version and hardware version of your UC511?

We have tested on the latest firmware seems work with the first test.

If you're not using the latest firmware, could you please upgrade it to the latest to test again?

Here's the download link.

https://www.milesight.com/support/resources/firmware

Wish you have a nice day.

0 Votes

Chiara posted 13 days ago

Dear Sirs,

I created a small reproducible test setup for Milesight irrigation valve behavior:

https://github.com/sfoglia/iot_tester/tree/main

If anyone has the same device, I would really appreciate if you could run the script and confirm whether the same behavior occurs.

==============================================================================
TEST 1

Description:
Send only a timed irrigation command.

Expected:
Valve opens immediately and closes automatically after 5 minutes.
==============================================================================
==============================================================================
Timestamp : 2026-07-05 10:47:27
Device : ***************
Command : OPEN valve 1 for 5 minutes
HEX : ff1da0022c0100
Base64 : /x2gAiwBAA==
Topic : ug/downlinkdata

MQTT Payload
{
"devEui":"***************",
"confirmed":true,
"fPort":85,
"data":"/x2gAiwBAA=="
}
==============================================================================
Result : MQTT message published successfully.

wait for timed execution to complete

Observation:

MQTT publish succeeds

No valve actuation observed

TEST 2

Description:

OPEN

wait 60 seconds

CLOSE

wait 5 seconds

OPEN (timed irrigation)

Expected:

Timed irrigation command should execute reliably

==============================================================================
TEST 2

Description:
OPEN
wait 60 seconds
CLOSE
wait 5 seconds
OPEN for 5 minutes
==============================================================================
==============================================================================
Timestamp : 2026-07-05 10:52:33
Device : ***************
Command : OPEN
HEX : ff1d2000
Base64 : /x0gAA==
Topic : ug/downlinkdata

MQTT Payload
{
"devEui":"***************",
"confirmed":true,
"fPort":85,
"data":"/x0gAA=="
}
==============================================================================
Result : MQTT message published successfully.

==============================================================================
Timestamp : 2026-07-05 10:53:33
Device : ***************
Command : CLOSE
HEX : ff1d0001
Base64 : /x0AAQ==
Topic : ug/downlinkdata

MQTT Payload
{
"devEui":"***************",
"confirmed":true,
"fPort":85,
"data":"/x0AAQ=="
}
==============================================================================
Result : MQTT message published successfully.

==============================================================================
Timestamp : 2026-07-05 10:53:38
Device : ***************
Command : OPEN valve 1 for 5 minutes
HEX : ff1da0022c0100
Base64 : /x2gAiwBAA==
Topic : ug/downlinkdata

MQTT Payload
{
"devEui":"***************",
"confirmed":true,
"fPort":85,
"data":"/x2gAiwBAA=="
}
==============================================================================
Result : MQTT message published successfully.

Observation:

OPEN works

CLOSE works

Timed irrigation command is accepted at MQTT level

Additional note (uplink / ack flow)

Observed device behavior after Test 2:

ug/downlinkdata → timed command accepted
ug/uplinkdata → valve task sequence_id changes over time
ug/acknotification → fCnt increments normally

Device telemetry shows alternating task states:

sequence_id: 2 → timed irrigation task present

sequence_id: 0/1 → intermediate/reset states

valve_status: 1/0 → switching states observed

However, final expected stable timed execution is not consistently triggered when the command is issued immediately after OPEN/CLOSE sequence.
Question

Is this:

expected firmware behavior?
a required internal state-machine constraint (cooldown / idle state)?
or a possible firmware issue affecting timed irrigation commands?

Any reproduction feedback from other users would be highly appreciated.

Thanks, BR

0 Votes

Chiara Tecnoelettrica posted about 2 months ago

Dear Aslan,

thank you for information, during testing, I observed that reliable operation requires a minimum activation time after issuing an open command before subsequent actions can be executed.

If the delay is shorter, the valve state does not consistently stabilize, leading to incomplete or missed actuation cycles.

To ensure correct operation, my current sequence is structured as follows:

send open command
wait approximately 60 seconds
send close command

send timed irrigation cycle (now it is executed, if I send only this command is ignored)

Could you please clarify:

What is the recommended minimum stabilization time after an open command?
Is there a preferred command sequence to ensure deterministic valve state (open/close acknowledgment)?

Device are in Class C mode realtime.

I'd prefer to send timed commands as OPEN_V1_5_MIN instead a sequence of open close, but need to understand the expected behavior would help ensure a robust integration.

Best regards

0 Votes

Aslan Lu posted about 2 months ago Admin

Hi,

Thanks for your reply.

Yes, the rain control could suspend scheduled task for a specified period.

Wish you have a nice day.

0 Votes

Chiara Tecnoelettrica posted about 2 months ago

Thank you for the information, you were right: now it works correctly after converting the payload to Base64.

I am currently using:

hex2b64 () {
    echo -n "$1" | xxd -r -p | base64
}

hex2b64 ff1d2000

Now I'm playing with opening with timer:

Byte Meaning
ff command group
1d valve task
a0 / a1 flags + valve index
02 sequence_id
xx xx xx duration LE 24 bit

So far I've made python script with tested:

COMMAND_MAP = {
"OPEN": "/x0gAA==", # HEX: ff1d2000
"CLOSE": "/x0AAQ==", # HEX: ff1d0001
"OPEN_V1_2_MIN": "/x2gAngAAA==", # HEX: ff1da002780000
"OPEN_V1_5_MIN": "/x2gAiwBAA==" # HEX: ff1da0022c0100
}

I'd like to add rainy days management but need to understand better what it does: this command would suspend scheduled task for a specified period?

P.S. these devices are truly well designed!