Jimbo.Automates

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

It is possible to add the triggering node in Email Customizations and Network Resources using ${sys.node.#.ST}, but is there a way to include the actual name of that ST driver? You might say in your message: Status: ${sys.node.#.ST} SomeName: ${sys.node.#.GV1} But would be nice to say: ${sys.node.#.ST.name}: ${sys.node.#.ST} ${sys.node.#.GV1.name}: ${sys.node.#.GV1} And just tagging @MWareman since he does a lot of this kind of thing

Sorry, first paragraph makes sense, but you lost me in the second paragraph, and not sure which if those programs you purpose be the UD Mobile favorite? And FYI, this is the simple program that I just wanted to add as a Favorite node in UD Mobile: That would be a simple toggle to show if it was Armed Stay or not and allow simple arming.

Using an integer variable as only condition does not work, it has the same issue, the program state doesn't change when integer changes value. On to try another workaround...

Yes, that was part of my request in the ticket. Sent from my Pixel 6 Pro using Tapatalk

Yes, I understand why this is, and I've submitted a ticket which @Michel Kohanim cc'd@Chris Jahn to get the experts opinion. That's another possible option you mention, but still just jumping thru hoops to achieve something that seems very desirable in UD Mobile. I've been trying to think of an enhancement in UD Mobile to handle this better, but haven't come up with anything that makes sense...

Thanks Javi, I was hoping for an easier workaround. That's a lot of work to do something simple in UDMobile especially since I currently have 3 similar programs. Program conditions are also evaluated when it is saved. Maybe I can convince them to add this as an option to always evaluate them. Sent from my Pixel 6 Pro using Tapatalk

Not what I'm saying. I want the idle True/False to show the proper status of the if statement when the conditions change outside of running the program. Sent from my Pixel 6 Pro using Tapatalk

I have a disabled program that I wanted to use as a UD Mobile Favorite, but a disabled program does not change status True/False when the items in the "If" change. If you update/save the program then it changes, but not when the nodes or variables change. I confirmed this with a simple program checking a variable value on latest ISY and IoP releases. So if this is not considered a ISY "bug", is there an easy way to work around it? I can't have the programs run from the triggers so they must be disabled, but I want to see the correct status in UD Mobile... I also tried putting them in a folder that was disabled with an if condition, and they also don't change status.