Jump to content

Error sending Open and Close commands to Yolink Valve Controller


landolfi
Go to solution Solved by Panda88,

Recommended Posts

Just purchased a Yolink valve controller to irrigate my garden and in creating a daily timer to water the garden, I noticed the switch control commands (Open and Close) do not work from the nodeserver and therefore I can't control the valve. Open and Close commands do work from the Yolink app. The AC correctly reports state and I can set the off delay in a program, just not the open and close valve commands. There is an error in the NS log, which I've attached.

YoLink_5-19-2023_33127-PM.zip

Edited by landolfi
Link to comment

Turns out the valve sensor was acting strangely because I had the wrong size hose attachment adapter on the output side. For anyone else who might have one of these, the male NPT adapter for the output of the 3/4 model should be 3/4 to 1/2, not 3/4 to 3/4 as I thought. The Yolink marketing material shows a picture of a 3/4 to 1/2 but does not specify the actual thread sizes and there is no info provided with the valve, only the controller manual.

Link to comment

I have a program that runs daily from 0800 to 0820 to water my garden. I send an on command to the valve, set the valve delay to 20 minutes, and then send an email notification to myself. Everything works fine. Not sure whether this is a Yolink issue, but at the exact time of the IoX email notification  (0815), the Yolink server also sends an email telling me that the valve "failed to perform the operation". The PGx log shows an error at that exact time, but as I mentioned the on/set delay is sent at 0800 and the 20-minute off command works as scheduled, so not sure why the error would occur 15 minutes after the successful ON. Could the node server be sending an extra unrecognized command that is causing the Yolink failure notification? It's mostly an annoyance becuase everything is working. Log attached.

YoLink_5-25-2023_62850-AM.zip

Edited by landolfi
Link to comment

It is an error that occurs with this type of device - I am told it is a special device type (class c) - I think what is happening is the device is queried (short or long poll) and does not reply (because is it busy with something else) - I guess it is to preserve battery.  It is just a guess.  I could look at excluding the short poll from class c devices - but I not even sure where to figure out what type the deviceis implemented as - My guess for Yolink it is battery power devices that can get control instructions, but just a guess. 

I have no idea why the node server is sending an email - it cannot do that from the code (there is no email support in the code).  It must be coming from somewhere else.

Do you use the yolink delay function in the valve controller  (I do that in case the internet goes down while valve is on - the delay timer runs on the device so it will shut off evenif there is an outage of the internet / power outage.

Link to comment
8 hours ago, Panda88 said:

I have no idea why the node server is sending an email - it cannot do that from the code (there is no email support in the code).  It must be coming from somewhere else.

Do you use the yolink delay function in the valve controller  (I do that in case the internet goes down while valve is on - the delay timer runs on the device so it will shut off evenif there is an outage of the internet / power outage.

Thanks for clarifying. It's not the node server that sends the email, it's the Yolink server sending it (sorry for any confusion). I'm attaching it just for fun.

Yes, I use the set off delay to get the 20 minutes. That "set off delay" function confused me in IoX until I looked at what was happening in the Yolink app after IoX had set the delay. I was able to see that the Yolink app was counting down from 20 to zero.

Your explanation makes sense because it seems the device is pretty battery intensive. I don't see the battery level in the Yolink Valve node in the node server, but the batteries appear to be about 50% after only about 20 open/close cycles.

YoLink Device Alarm YoLink Valve.msg

Link to comment

I verified the battery level is not show - something happened to the valve controller in my code - it used to be there - probably a bad checkin :-(

I have never seen a message from the Yolink app when controlling devices, but I may have missed it - or you may use a different setting

Link to comment

Thanks for adding battery level!

Still getting the error/Yolink failure notification (log entry below) but I think you said it will continue. I just ignore the email I get from Yolink, so it's not an issue since the operation always works.

 

2023-05-27 08:15:04,451 Thread-1078 udi_interface      ERROR    yoLink_init_V3:process_message: Non-000000 code Can't connect to Device : {"code": "000201", "time": 1685193304409, "msgid": "1685193300216", "method": "Manipulator.setState", "data": {}, "targetDevice": "d88b4c0100060595", "desc": "Can't connect to Device"}
2023-05-27 08:15:04,452 Thread-1078 udi_interface      INFO     udiYoManipulatorV2:updateStatus: updateStatus - udiYoManipulator
2023-05-27 08:15:04,453 Thread-1078 udi_interface      ERROR    yolink_mqtt_classV3:updateCallbackStatus: Manipulator: Can't connect to Device
2023-05-27 08:15:04,456 Thread-1078 udi_interface.node ERROR    node:setDriver: 8b4c0100060595:YoLink Valve Invalid driver: BATLVL
2023-05-27 08:15:04,533 MQTT       udi_interface.interface INFO     interface:_message: Successfully set 8b4c0100060595 :: GV1 to 0 UOM 57
2023-05-27 08:15:04,568 Thread-1079 udi_interface      ERROR    yoLink_init_V3:process_message: Non-000000 code Can't connect to Device : {"code": "000201", "time": 1685193304483, "msgid": "1685193300260", "method": "Manipulator.setDelay", "data": {}, "targetDevice": "d88b4c0100060595", "desc": "Can't connect to Device"}
2023-05-27 08:15:04,569 Thread-1079 udi_interface      INFO     udiYoManipulatorV2:updateStatus: updateStatus - udiYoManipulator
2023-05-27 08:15:04,570 Thread-1079 udi_interface      ERROR    yolink_mqtt_classV3:updateCallbackStatus: Manipulator: Can't connect to Device
 

Link to comment

Battery level is back. I hadn't changed anything and it looks like I'm still on the same version. Friday battery level showed %, now it just says Medium.

EDIT: This device seems to be really flaky in reporting its status. For a period just now it was showing all attributes except the timer delay time remaining, then it showed the timer delay but all other attributes were unavailable, now it's showing everything including the timer delay countdown. But the timer delay is already over, the valve has been closed for 7 minutes, and it's still counting down showing 8 minutes to go.

Edited by landolfi
Link to comment

Let me take a look at the counters tomorrow - The couner display is running independend of the actual device (In order not to drain the battery).  It is simply counting down

I do not understand the battery % - there is no such info - it is a 1-5 value reported by the device.

 

Link to comment

Thanks for looking into the counter. The way my IoX program works, the IoX email notification (which simply tells me that the valve is on) is supposed to occur immediately after the off delay is set. It seems to me that would mean it takes a second to set the off delay and then send the email. But for some reason IoX is not sending that email notification until 15 minutes later. As if the valve off delay takes 15 minutes to complete successfully as far as IoX is concerned. So the sequence as it is: 1) Valve open at 0800 (which it always does), set off timer for 20 minutes (which takes 15 minutes to complete), 3) send email notification that valve is open (occurs 15 minutes after original valve open at 0800. Also I forgot to mention that the valve shuts off at 0820. So apparently the delay is getting set immediately at 0800 as it should.

It only did the battery % once that I saw (it showed 99%).

Edited by landolfi
Link to comment

99 - means unknow (when not mapped) - it was probably before the new mapping took effect 

I personally set the off before opening the valve - just to be 100% safe

It would be interesting to know if the delay is the one delaying the next command - It should not be the case (I hope) 

 

 

Link to comment
Guest
This topic is now closed to further replies.

×
×
  • Create New...