Jimbo.Automates

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

So what is the fix? Something we can do before installing to not have the same problem?

What tag type is that? I'll try to find time when I return home to exclude the new options from it. Sent from my Pixel 6 Pro using Tapatalk

Thanks, yes, I need to remove the poll options, they don't work with PG3 currently. I thought users might want to change the values in a program, not sure if anyone actually does that.

@wmcneil Thanks for confirming. Sent from my Pixel 6 Pro using Tapatalk

Those are new values they added recently, obviously they didn't add it to all tags. It's actually causing errors with leak sensors, I've asked their support to fix it. If I don't hear back I will remove it when I return home after this weekend. Sent from my Pixel 6 Pro using Tapatalk

Sure, I can look into that sometime, but doesn't Kasa have an Alexa method already? Why use it through the ISY? Sent from my Pixel 6 Pro using Tapatalk

Thanks @bpwwer for fixing that! I have uploaded 3.1.4 now.

That does make a little sense, if you have moved to IoP. When you reboot Polisy then when ISY On Polisy starts up and Query All on restart option is enabled, it spends a lot of time querying all nodes on PG3 so it's very busy. Waiting for the initial Query All to complete is best before messing with anything on PG3 like adding or deleting NS's.