Jimbo.Automates

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.

Did this just show up or always been happening? What changed? Sent from my Pixel 6 Pro using Tapatalk

I created this issue a while back, will try to look into it. https://github.com/UniversalDevicesInc-PG3/udi-wirelesstag-poly/issues/52 Sent from my Pixel 6 Pro using Tapatalk

No, that's it. Glad they found and fixed the issue. Sent from my Pixel 6 Pro using Tapatalk

Those messages are on the controller node since they will apply to all service nodes. Sent from my Pixel 6 Pro using Tapatalk

Support finally got back to me and said: I found the issue. The signal and transmit power were not supplied if the "buffer multiple data point" option is enabled. It is all fixed now, please try again. Sent from my Pixel 6 Pro using Tapatalk

Ok, then I'm not sure what is going on since this way works with my tag type 12 and supposedly this was a server side update so everyone should see it... Can you try rebooting your tag manager, then restart the Node server and see if it goes away?

Well, I did, but looks like it upgraded last time succesfully? Tue Mar 8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios product: Polisy Tue Mar 8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios ver: 1.0.0 Tue Mar 8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios version 100 is old and needs to be upgraded Tue Mar 8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: starting forcing bios update Tue Mar 8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios mfr: Universal Devices Tue Mar 8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios product: Polisy Tue Mar 8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios ver: 1.0.0 Tue Mar 8 17:27:48 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios update ... rebooting Tue Mar 8 17:29:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios mfr: Universal Devices Tue Mar 8 17:29:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios product: Polisy Tue Mar 8 17:29:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios ver: 1.1.3 Tue Mar 8 17:29:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios has the correct version

That's odd, looks like a tag type 12 which is working fine for me. Does it show like this in the admin console?

Yes of course I realize that. I just don't want to get stuck in a boot loop like @simplextech since I have 3 very early versions as well. What can be done to prevent that with the original ones was my question. Sent from my Pixel 6 Pro using Tapatalk