Panda88

I updates node info - it is a minor change addressing when you have a very large amount of devices installed - I cannot test if it works, as I do not have enough devices to test it

it would be guessing - but is looks like a calculated 0 (not yielding exact zero)

Correct - it is an attempt to limit simultaneous quering when you have a lot of devices - The YoLink MQTT disconnects if you querry too often - no other changes

I have not had this issue - it may be an issue with your specific unit Glad it is working again

As far as I am aware it should be ok to try first. It is the same code. When you purchase there will be an option to replace the existing (trial) node. Just PG3 handling the trial and it should be registered the same in PG3. I have personally done the same with other node servers without any issues. I cannot really try myself as as a developer of the node I am treated differently

I tried to add some code to try to reconnect - I am not 100% sure how the node fails without log, but I gave it a try It is under beta test TesleEV_Beta (0.2.55) - let me know if it works - I have no way to test as I do not own a car I also updated how I believe car is sleeping works now (API changed) Let me know if this works and/or has errors

Bob is likely the better resource to ask here

Did you try to upgrade PG3 - There have been some issues with not being able to delete files in some versions

Hi 0.3.68 New release with support for Utility Season, Utility Period and Utility cost (added to status node) - Kept config parameters for periods - The added info comes directly from Tesla - likely from App when you select utility provider

Did you try to upgrade from the AC - I heard there was a bug the prevented deletion of files in a prior version

OK - I'll think about how to do this

Do you haver a screen shot and log - It is always difficult to predict how the node fails, so If I can determine the failure, it should be possible to add the automatic reconnect

Does it come back on0-line later There are some limitations as to how often you can send commands to yolink Can you enable debug and send me a log where it happens (as a file preferably)

I think you should just use DON / DOF - Fast on and fast off are representing double clicks from Insteon devices used in programs - not scenes (as far as I understand - I am no expert here). It is not related to speed - it is 2 different click types.

Can you try to erase the FOB and the 4 sub keys (there may actually be 2 sets of 4) in the nodes in the PG3 browser interface (and in the AC) to be sure. and then restart the node server. It looks like the keys somehow did not get installed correctly. I have seen this before when upgrading the node and/or PG3 What are you trying to achieve with the scene? Can you show me the setup pf key4 (the yolink key4 line/device)

You should be able to use directly in a scene as long as you configure the function of the keys - I did not 100% follow your approach from before - but I did not spend a lot of time on it as I was working on fixing the issues in the remote code

The FOB keys are reset to defaultupon install (from versions before the latest) - so if you changed anything you need to reconfig in the AC - The new release is supposed to remember the settings upon restart I need the log from the node - ideally with debug enabled

This is how I envision the use . The toggle function (long press) is used directly in a scene - as a controller - It will send DON followed by DOF on next click and so on The ON (DOF) (short press) will be sent to a program as control waiting for ON (switched on) - that way ON will be sent each time the switch is pressed. I do not believe that I did change anything on the status but let me know if something changed. I do not think I touched this part of the code, and it seems to be working in my tests (but I did not test excessively on this one as I do not believe I changed anything)

Can you send a log - did you reconfig the triggers?

Uploaded version 0.8.88 - should fix toggle and ghost triggering for remote

Did you select control vs status when programming ?

It seems to be the same issue I mentioned before - the short poll is actually executing the DOF

Do you have a node server log of this - ideally with debug enabled I wonder if the issue is with the switch also sending a command - I thought I had eliminated this but there may still be a bug. I'll check in parallel after I finish my changes to the remote - The current code has an issue with the polling causing the last command to be executed again - so if something else changes the controlled devices' state, it will execute

Do yoo just need the temperature or do you need the rest of the control as well? Getting the temperature is simple - making a control look that works is a lot more complex

I believe some users have found the correct settings - I think the long poll cannot be too small otherwise the node server keeps the car alive. I do not own a car myself, so it is a little difficult to investigate this - I have some code that is not released yet to check if the car is going to sleep - but I am not 100% if it works. I think other users can chime in - or look is some of the other threads for the best long poll and short poll settings. If you pull data yourself regularly (in a program) the car will not go to sleep for sure - I would only pull when needed (not just to keep data updated for now reason besides showing the data) - thus the large long poll requirement (long poll updates the data)