Panda88

I have not tried the specific use but it should work - the plug reports power and you could even use the Yolink alarm for power to create triggers in case the power reading does not work There is room for a normal plug in the second outlet if needed

Still working on it - we have a server now by Universal devices that helps send the commands - it is not stable yet, but it is making some progress - we can send a command some times

I tried my water sensor and over night it went offline - as expected - It may work now - there is no difference between sensors as they call the same functions (assuming the YoLink API acts the same)

If it happens again save the log. It should be possible to debug - it is always a guess when the API is not fully documented. I can try to pull a battery in one of my sensors to see if I can see a change

Can you send me the log file - you can message it to me Did you make sure there is no space at the end of the UAID and Secret Key Just to be cleat - the node shown is the PG3 node (to show it state) - it is not the HUB = there is no node for the hub as it offers no functionality - there are no Yolink devices imported

I got a little more info - they use special channels in the APP (not available to the API) From support: I'd like to clarify the difference in detection speeds between the app and the API. Direct Device-App Communication The app communicates directly with the cloud platform in real time via optimized channels, allowing it to receive data almost instantly when a LoRa device transmits a signal. This is further enhanced by the use of push notifications, which are highly efficient in delivering updates immediately. API Request and Response Overhead On the other hand, API interactions rely on a request-response mechanism, which can introduce minor delays. This includes the time needed to: Establish an HTTP connection. Send the request. Wait for the server to process and respond. Handle authentication and authorization processes. These steps can cause slight lag. API Rate Limits and Throttling In addition, our API is subject to rate limits to ensure fair usage across all users. Specifically: A single UAC is limited to 100 API calls within a 5-minute sliding window. A single target device can receive no more than 6 API calls per minute, with a minimum interval of 200 milliseconds between calls. These restrictions help manage overall performance but may cause delays in scenarios requiring frequent updates. I hope this explanation clarifies the differences. If you have any further questions, feel free to reach out. Best regards, Thomas | YoLink Customer Support

I heard back. It can take up to 3 reporting before it will be shown as off line. The reporting interval is up to 4 hours so it can take more than 12 hours before a device will go off line.

Let me send them an email and ask how to determine on line off line

In your log there are 348 cases on 'online' parameter being returned - 343 are true and 5 are false. In the case of 5 false the same return structure also has a 'online' = True??? the 5 with false covering 5 different devices - all occured arounf 12:53. Maybe an internet issue I really do not know how to determine the if the device if offline or not - all report true Do you know at what time you unplugged the battery?

I assume the log with bad data was earlier than the log you sent Did you notice if other data was valid or unknown when the device was offline My code was supposed to follow the online state, but there is a bug so the actual state does not get updated - data should be unknown If data is valid I need to get a logfile to see what the data looks like - I may be able to recreate it later Thanks

Can you send me a log file - Yolink keeps changing how they report on-line Please enable debug before getting the log file Christian

i looked at it before. did not find an easy solution. it has been a while so it may be possible but it will take some time i usually handle this by running a special program on boot of ISY

ok - I'll remove them and make a new release

is it ok if I remove the bottoms

The buttons are not working now I can enable them again - I removed them, but forgot to remove them in the profile so they show up but with no function I think you need to test the sensor working From what I can see (besides timing) it should offer then same as the insteon (I have) It can trigger only on alerts or trigger on both alert and when no alert happens - My node further offers to only trigger on no_alert Note, it send DON for alert and DOF when no_alert happens

What function is it you need? - I think you can set the motion sensor to only send on Motion, and when it exists motion (that is the new field) The 2 buttons are to force a motion event - you can do the same in a program by running the then event

OK - I can take a look - you are correct They no-longer work - do you want me to remove them? Probably no real use

They are supposed to send trigger (DON / DOF) like the motion sensor would do - allowing you to trigger a scene/program - you can look in PG3 log to see if a cmd('DON" .. ) is sent I thought it works but I could be wrong It may not be of much use - I am not personally using them

Erasing the node in the node server (PG3) does are bigger reset that from the AC - You need to find it in the list there I doubt it helps when a new node does not work - but may be worth a try

I meant to erase from the node - not the AC

Can you send me a log file with debug enabled and trigger the motion sensor a few times You can also try to erase the motion sensor and restart the node

I think something is wrong with your version Mine looks like this - you can select if only DON (motion) DOF (no-motion), both and none can be selected My understanding is that this is want triggers the AC integration outside programs - I believe this is what you are looking for. The motion and NoMotion buttons are to send a DON/DOF from the device (even if there is no motion) Does yours look different?

Can you specify exactly what you need and I can talk a look - I have not looked at the motion sensors for a while so I may be able to improve on them

I think it may be filtered at a higher level I think you can test on Motion under control - it should only trigger when turned on

Let me think about it - It should be possible to have it send only DON (or DFO for that matter)