IoT Support

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

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!

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