-
New Release 1.8.45
Can you send me a log where you issue a control event - It is supposed to send DON DOF
-
Trapeeze Mousetrap?
As it is said - its core is a vibrationSensor so it is already supported Wish they made it for rat-traps as well
-
-
New Release 1.8.45
1.8.56 released Minor bug fixes. Water meter measure was off for some meters (correction factor) and old thermostat issue. Was trying to fix the UDmobile issue with labels not showing, but it is believed to be a known issue with current udx release, so hopefully it will get fixed with an upcoming release of this Does anyone have issues with scenes not triggering from sensors? One user has this issue, but I cannot reproduce it here. May be the same udx issue mentioned above (but less sure about this one)
-
Local vs Cloud
You can easily have multiple hubs - You only need the local hub if you plan your system to operate without internet access (for mission critical operation). Not sure there is a big difference in speed I would say unless you need its benefits, I would not buy the localHub - if you think you have marginal coverage, you can always buy another "normal" hub
-
New Release 1.8.45
Most likely it is the schedules - yolink operated schedules are now separate child nodes (I did not look at log yet)
-
New Release 1.8.45
Can you send me another log with it working - it may help identify the issue
-
New Release 1.8.45
Working to get some help - Have other experienced this One temporary solution should be to use status (not control) of the motion sensor in a program to trigger your scenes - I assume that would work - from the log I can see status changing - adds a small delay but not significant
-
New Release 1.8.45
I have contacted UDI to see if they have any idea
-
New Release 1.8.45
There are 5 of your door sensors that do not register the DON/DOF (triggers for scenes or actions) - others do not have this issue - You can see what they are if you look in nodes in pg3 interface Line 5763: 2026-05-12 01:43:43.741 Command udi_interface.node ERROR node:runCmd: node 8b4c01000e752f command DOF not defined Line 5764: 2026-05-12 01:43:43.781 Command udi_interface.node ERROR node:runCmd: node 8b4c01000e735a command DOF not defined Line 7098: 2026-05-12 02:16:54.781 Command udi_interface.node ERROR node:runCmd: node 8b4c01000a41c7 command DOF not defined Line 7099: 2026-05-12 02:16:54.824 Command udi_interface.node ERROR node:runCmd: node 8b4c04000354c2 command DOF not defined Line 9269: 2026-05-12 02:40:37.239 Command udi_interface.node ERROR node:runCmd: node 8b4c0200013692 command DOF not defined Is there anything unique about them? It must be coming from PG3 as other door sensors are using the same code and work well - Is this related to the zwave devices not working - e.g. are these doorsensors paired with ZWave in scenes or similar?
-
New Release 1.8.45
Yes - I can see this in your log the node reports it does not know the trigger commands to scenes. I do not see this in other logs which is strange, Could you try an thing - try to back up system, delete the node , reinstall it and restore the backup I also need to look at linking - it seems to be needed for zigbee/zwave, but I have never needed to use it before - maybe something has changed
-
New Release 1.8.45
udimobile has stricter rules for the node definitions than AC. I need to find a bug somewhere - I do see it on my side as well (Not a big user of UDImobile so I did not check) Do you know how to run the java console and see if there an any warnings when you start AC. Also, did you check if there is an update to PG3 (from the AC)
-
New Release 1.8.45
I think it is expected that the 2 swithes start as unknown - there should be 2 sub nodes (one per botton) - The bottons are like the remote, where you can assign a short press to generate DON (switch on) DOF (Switch off) DFON (fast switch on) DFOF and toggle (DON/DOF) or (DFON/DFOF) Once you press the key it should update from unknown If that is not the case send me a log with debug enabled and where you press the two keys with short press and long press and I'll see what I can do - if that does not work I may take you up on the Amazon offer :-)
-
New Release 1.8.45
Updated version to 1.8.51 - Fixed a needed correction factor for certain water meters - should report correct now (not 10x)
-
YoLink Device Support Question
Forgot to mention the yolinkLocal is a superset of Yolink node server, so if you plan to go to localHub in the future, I would get that - there is no upgrade path (UDI does not support this in the PG3x system). Without localHub they should behave identical
-
YoLink Device Support Question
Yolink offers a waterdept sensor - I have not tried it myself - I think it has +/- 1 inch accuracy - I assume it could work. You can likely adjust it to become more accurate, but it will likely change with weather (My guess) I personally use a Yolink alarm power unit (it is really a power supply you can turn on and off) and then a door sensor with a float sensor (with a small circuit added) replacing the normal sensor. The circuit on the float ensures the door sensor only can change state when powered by the alarm - I then only turn the power on when I need to see if the pool needs filling (once a day) - It is a little complex but it is from before the water dept sensor was available - I assume you can hide the dept sensor inside a skimmer (like i currently do ). The issues I had with the traditional float was it ran out of battery quickly as waves in the pool when close to the filling point would sends changes all the time draining the battery - I know Yolink talked about an improved algorithm but not sure if it happened. Naturally you can control the alarms to set the rearm time long and if you fill on first trigger the sensor should not trigger after you fill the pool - the sensor was not good in high humidity either (I had to have it in a "waterproof" box ).
Panda88
Members
-
Joined
-
Last visited