Panda88

Sorry - no - click download log - make sure debug is enabled Best if you can restart after enabling debug, wait a little, and then click Download Log

Can you enable debug and send me the node log (not the PG3 log) - that will help me understand the issue

I think I can receive messages again - hit a limit Can you send me a log with debug enabled - and let me know when you pressed the update (roughly in time) Also if you can turn the switch on and off in the log Found a bug for Alert

I found a few of the bugs - I still need to figure out the time jump issue - I'll try to release a patch release once I have the last bug ironed out

can you send me a log with debug enabled. there must be a bug somewhere but i need to know what the device reported you can pm it to me. enable debug under logging. update sensor —set log back to info and download log - just the pg3 log i did find a bug but nit related to this

Can you send me a log with debug enabled. It may be I mapped alert wrong - it is likely charging. I did add new functionality in the localHub to allow it to detect if it is operating of its own battery or by power from outlet, but it seems Alert is not the correct message. I do not own a flex switch - I should be able to identify the issue from the log I think the last NS-70 message is beyond the node server layer but I'll check

Do you need anything changed? I do not 100% follow - if yes, can you send a log with debug enabled (just PM me) Can you send me a log with debug enabled - There were changes to THsensor and LeakSensor as new functionality we enabled in the API (and I wanted to include those) - There is likely a return from the API I do not know of that may cause the unknow state to appear (if the device is not reporting its value in this return _ I just need to ignore it missing) Can you validate the device types you have - the node sees the garage sensor as T only - look at the name - They must have different types YSXXXX-UC in the app ... area

Legacy has been there a while :-) (previous release had it also) - the two are the same - It is to be able to assign the ST parameter to the main function of the node - not just online - This is to show in UDImobile and also an issue with how the system handles variables I tried to reduce the number of functions (some a doing the same) as they take u a lot of space on AC Is open/close swapped in the manipulator?

Hi I added a new BroadLink node server (BroadLink). It currently supports RF and IR code transmitters as well as the optional temp/Humidity sensor cable. It supports learning codes (@ 430MHz and 315MHz) remotes as well as IR codes (I have not been able to make it work for 305MHz RF controllers, so check the FCC ID to know the frequency of operation - or check with Broadlink). The node created a main controller node (per hub) where the sensor is a child node (if available) - the IP address is embedded in teh name). The node spins separate RF controller and IR controller nodes (with IP addresses in the name as well). Each code learned becomes a child to the respective node and you transmit it from there. You can rename the created codes. It will not allow generation of 2 identical codes (RF for sure - not 100% sure about IR codes). To erase a code (limit of AC) you either ungroup the node, delete and then regroup or erase in the polyglot web interface. Configuration required HUB_IP and TEMP_UNIT The node supports multiple hubs (list them under the HUB_IP space or comma separated) The node assumes the hub is already assigned to the Wireless network (has an IP address). The easiest way it to use the BroadLink app go as far as where the hub is assigned to the WiFi network - stop after that - If you complete to the end, but hub gets locked and cannot be controlled by the node- This also means you cannot use the APP in parallel It should be possible to add other BroadLink devices, but I do not own any so I cannot test it. Contact me if there is interest Enjoy (I hope :-))

not all devices have schedules :-)

Hi A new release of the Yolink node server (ver 1.8.45). There is a lot of changes below the surface to handle the Yolink API better. Node should be faster and take less resources. Added quite a few devices (Most of the newly released devices and Thermostat2) and updated a few sensor nodes (The Yolink API was updated - THsensor and LeakSensor ) . Note, the new LeakControllers behave a little different than other devices - they go to sleep. Given this one should use the YoLink specified limits to trigger events. Also, they cannot sleep when added. YoLink schedules are now in separate child nodes. As this is a major update, so devices may not work - I have tested the ones I own, but there are derivatives of the devices and a few I do not own, so please help test and let me know if something is not work correctly Note, there is a minor issue with the Dimmer - there is an API problem YoLink is working to fix - I hope once they release the fix the issue is gone, but I have not received the fix yet (probably low priority as it only related to controlling some attributes) - nothing critical

Hi I added a node (KiddeSmokeDet) supporting Kidde Smart Smoke/CO detectors. It is a simple node that pulls data from the Kidde cloud showing if alarms are detected - it also shows CO level and smoke levels It is a main node with child nodes for each Alarm detected It offers simple control to test, Identify and hush the alarm Note, the Kidde API does not seem to poll the alarm when called - just reports the latest data send by the alarm - it may not make sense to poll that often ShortPoll is a heartBeat and LongPoll obtains latest data from the Alarms Note, it is only tested with the DETECT type Smart alarm

Can you send a log. It is possible they have change the api again. Also did you verify the webhook test passes

I am working on a release that supports the thermostat device - we only tester version 2 but API is the same so likely yes

There are some devices in the log that show offline (code 000201) - often you just need to press the set button There is a bug in the THsensor - I am working on a new release that should fix this - it is a race condition during start up I hope to have a release soon - if not I'll move the fix back an release a fix Is it all devices that show the year old data or only a few ones?

Can you send me a log with debug enabled

The current release does not support it. I am working on an update that supports it - with other internal improvements Hope it can wait until I release the new version (it is a bigger update to easier handle Yolink changing API calls)

Are you sure it is not working after restart = no ERRORs reported - the should show as individual nodes I see a leakSensor a temperature sensor and the water controller (and a hub) - They all report data There is still an issue with the leak sensor Ibelieve - Yolink updated the API so some data is reported differently (basic leak detection should still work) - I am working on an update for the node and it will get fixed with that release (it is a bigger update as I am changing the internal structure of the data - to allow easier changes when Yolink change the reported data)

all nodes are separate. hub is just a node

Can you try to include a restart in the log file - just restart with debug enabled I can see some errors, but not sure what causes them - it is like data is not reported correctly Sometimes PG3 has an issue and need to be restarted - I think it relates to both solutions uses MQTT (but just guessing)

Can you send ma a log with debug enabled - you can PM it Not sure what watervalve you have -= some need to press the set button the first time to activate - they go to deep sleep Also what do you have in the config?

Do you have a log - Maybe it does not report it (or reports it differently) - I do have one but not installed it yet

Thanks - it is actually a missing update - hopefully 1.6.11 fixes it (just released)

Currently no but i can work with you too get it added if you can provide logs once I get the basic code added I never hear agrees to one so no support so far

Just updated to 0.6.6. There was an update to the underlying API (likely a bugfix) - so a new version is needed to force the latest API use