Jimbo.Automates

I did an install on my dev box and got the same error, so it's not just you @macjeff

Send log Package to @bpwwer Sent from my Pixel 6 Pro using Tapatalk

I upgraded to PG3 3.0.53 and all are working for me.

This is an error because PG3 is not sending the information needed by the NS. Need help from @bpwwer Sent from my Pixel 6 Pro using Tapatalk

Thanks, I've not had a chance to look into any issues, glad it's working. Sent from my Pixel 6 Pro using Tapatalk

3.0.52 is out and others are reporting that fixes these issues. Sent from my Pixel 6 Pro using Tapatalk

There are many posts about this already. We are aware and @bpwwer is looking into it. Sent from my Pixel 6 Pro using Tapatalk

This is a PG3 issue which seems to affect all NS's, will have to wait for more info from @bpwwer

This is a PG3 issue which seems to affect all NS's, will have to wait for more info from @bpwwer

This is a PG3 issue which seems to affect all NS's, will have to wait for more info from @bpwwer

Yes others are reporting issues with many node servers and the latest PG3, I've not been able to test it yet. Sent from my Pixel 6 Pro using Tapatalk

He said this was for the Kasa Node server, doesn't really mater what firmware or UI Most likely the Kasa library is not sending a power number when it's off, so the NS didn't change the value because it was missing. But should handle it properly in the Kasa NS, issue created https://github.com/UniversalDevicesInc-PG3/udi-poly-kasa/issues/6

PG3 3.0.48 is now released which should fix this issue.

Well that's the problem, he didn't announce this version and currently there's no way to release test versions so you'll have to wait for a fix from him Sent from my Pixel 6 Pro using Tapatalk

What version of PG3 are you guys on? @bpwwer says this may be due to 3.0.47 release which wasn't meant for everyone yet. It shouldn't be an issue with 3.0.46 Sent from my Pixel 6 Pro using Tapatalk

This seems to be caused by a change to the PG3 store, I've pinged @bpwwerfor his advice. I'm out today and tonight and traveling tomorrow.

Ok, I'll try to take a look at it later today. Sent from my Pixel 6 Pro using Tapatalk

Please download log package and send it to me. Sounds like PG3 is not sending out the auth codes. I'll also try to reinstall on the dev box to see if that happens. Sent from my Pixel 6 Pro using Tapatalk

It shouldn't matter for PG3, I thought @bpwwer added a check to not push the same value? Sent from my Pixel 6 Pro using Tapatalk

Thanks for all the details, much appreciated. 1. That's what I did, only request initial state of integers so I'll just use those when I need initial status. 2. Good point, I did that, since I rarely use it in development. 3. I had already increased mine to 5 minutes, didn't want to go much longer for fear of battery drain 4. This is possible from a couple PG2 nodes I still use. Unnecessary updates should not happen with PG3 since Bob improved it, but we can still see updates for some things more rapidly like wind speed and constant temperature changes in wireless tags. The WeatherFlow NS has a way to turn off rapid wind speed changes, but I like to know about high wind guts asap. Maybe I'll shut down the PG2 ones I still have like Blue Iris which I currently don't really use. But watching the event viewer I don't see a lot of craziness coming thru.

Using a Program as the Status Node in a Command takes a lot longer to show current status when initially opening favorites. It takes ~11 seconds to see the Armed Status node, but ~1:45 for the program status to show up... Yes I have a lot of nodes and programs, and this was when using portal as well. Using a Variable comes up after ~18seconds, so I'll use that instead.

Yeah, not sure. For this I want the simplest interaction since I usually have my hands full backing out of the driveway or holding dog leashes and I only Armin stay or away mode most of the time. Sent from my Pixel 6 Pro using Tapatalk

Oh okay. Makes sense. So now I'll have to create the extra program like you mentioned to show color status different for each. Sent from my Pixel 6 Pro using Tapatalk

Thanks, yes I already do this with the original program mentioned and monitor the status of the armed state node. But I found what looks like a bug in UD Mobile. I have 2 similar commands, one for armed stay and another for armed away. When I configure the color mapping for one it changes both? May have to send you a video tomorrow. Sent from my Pixel 6 Pro using Tapatalk

Thanks @Javi now it makes sense, the part that wasn't mentioned or I didn't see was to use COMMAND, not a node reference program. I already use command and was looking for a cleaner way to implement, and a disabled program seemed perfect. Sent from my Pixel 6 Pro using Tapatalk