Jimbo.Automates

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.

I didn't see your update In the future post a new comment so it's more obvious. But yes, the PG3 python library was not updated, so deleting and re-installing forced it to update. Future versions of PG3 should force an update of that library when it's updated.

No worries. I've not heard back yet from support, and I'm heading out of town for a few days in the morning, so probably won't have time to put in a fix for this tonight. In the meantime you'll have to edit that URL and remove the singnaldBm and txpwr from the url manually, or turn it off.

If you are seeing multiple copies running after a fresh reboot of Polisy, that mans PG3 is crashing. @bpwwer and @Michel Kohanim are working with another user to debug that issue. Yes, there are new versions of almost all my NS's which improve how they shutdown when PG3 asks them to. But, there is currently a bug in PG3 that it's seeing the new verisons, but not downloading them. @bpwwer is aware and working in a fix.

I upgraded my dev box and I don't see this issue. Can you set Log to Debug and restart the NS, and if it happens again download log package and PM that to me?

The HueEmulator PG3 Node Server 3.0.5 is released. See the README for more information, including information along with the Release Notes But, the current PG3 3.0.44 is broken, so it won't be downloaded until the next PG3 version is out.

Yes, the new version is there, but the store is having issues while he is working on getting production, non-production, and local stores all working properly. That's the struggle with using Alpha versions Hopefully will get straightened out today.

Sometimes they don't respond to support tickets for a few days, so I'll have to generate a new release that exclude those setting for the leak sensor, will try to do that tonight.

That's bizarre, they just added the signaldBm and txpwr to their servers for us last week. The upgrade is not due to PG3, it's because when PG3 was restarted it checks and updates all NS's to the latest, and that change was released to the WT NS about 9 days ago. So it looks like they didn't add those settings for the Quad Leak Sensor, I will ping them on the support ticket.

I've got a new version ready, but looks like the PG3 store is broken and I can't upload it currently.

For the error, I added a new issue for not setting alarm state on the Area: https://github.com/UniversalDevicesInc-PG3/udi-poly-ELK/issues/71 Will work on that ASAP, but it still doesn't answer the zone status not changing.

That's odd if it's not changing status in the AC, I see both cases coming in these log lines 2022-03-06 15:47:01,324 Thread-3 udi_interface INFO BaseNode:set_driver: main CO mstr hal:zone_31: set_driver(GV0,3) 'Physical Status' = 'SHORT' 2022-03-06 15:47:01,454 Thread-3 udi_interface INFO BaseNode:set_driver: main CO mstr hal:zone_31: set_driver(GV0,2) 'Physical Status' = 'EOL' And I see those values being pushed to PG3 which should get there and then pushed to the ISY. But this was just a log, not a log package so it doesn't contain the PG3 log. But, there are some errors in other areas of the log where it's trying to set alarm_state to a semicolon, which I don't understand, I'll need to read the ELK docs again to see how that can happen. It's causing this error in the log: 2022-03-06 15:47:01,440 Thread-3 udi_interface INFO Area:callback: area_1:Area 1: cs={'alarm_state': ';', 'alarm_memory': '1', 'arm_up_state': '0'} 2022-03-06 15:47:01,440 Thread-3 udi_interface INFO Area:set_alarm_state: area_1:Area 1: ; 2022-03-06 15:47:01,441 Thread-3 elkm1_lib.elk ERROR elk:_got_data: Invalid message '1EAS0000000001111111;00000000004' Traceback (most recent call last): File "/var/polyglot/.local/lib/python3.8/site-packages/elkm1_lib/message.py", line 67, in decode self.call_handlers(cmd, decoder(msg)) File "/var/polyglot/.local/lib/python3.8/site-packages/elkm1_lib/message.py", line 55, in call_handlers handler(**decoded_msg) File "/var/polyglot/.local/lib/python3.8/site-packages/elkm1_lib/areas.py", line 80, in _as_handler area.setattr("alarm_state", alarm_states[area.index], True) File "/var/polyglot/.local/lib/python3.8/site-packages/elkm1_lib/elements.py", line 56, in setattr self._call_callbacks() File "/var/polyglot/.local/lib/python3.8/site-packages/elkm1_lib/elements.py", line 45, in _call_callbacks callback(self, self._changeset) File "/var/polyglot/pg3/ns/00:0d:b9:53:c6:f0_4/nodes/Area.py", line 88, in callback self.set_alarm_state(changeset['alarm_state']) File "/var/polyglot/pg3/ns/00:0d:b9:53:c6:f0_4/nodes/Area.py", line 171, in set_alarm_state val = self.elk.alarm_state if val is None else int(val) ValueError: invalid literal for int() with base 10: ';' The above exception was the direct cause of the following exception:

@wmcneil Please set logging to "Debug + Modules" in the PG3 UI for the ELK NS, then activate the CO detector, Download Log Package and PM that to me and I'll take a look. I tested my smoke/co sensors a long time ago and they triggered but maybe something different with yours. You'll want to but log level back to warning or they will grow pretty large.

The error types are in the README - Service Nodes There is no way to tell which message caused the error if multiple are sent at the same time, you'd have to handle that in the ISY programs. Unless you can think of how the NS could help with this, I'm not sure what can be done. You can create a unique service node for your emergency messages, and flag the error condition differently on those which will increase your chance of just catching errors for those. The retries is a option specific to Pushover Emergency messages, as mentioned in the README above. It is not related to the NS retrying on a failure to send. A failure to send sets the node status each time it happens, and is not reset back until a message goes thru. The methods used by the NS are a big improvement over using NR's or email directly from ISY, but I'm always open to suggestions for improvement.

Thanks, I've had the programming issues with using scenes figured out for a while. But if switching to z-wave I'm not sure there is a speed advantage over programs so may no longer be an issue, insteon in scenes are so fast...

I had purchased a Zooz ZSE11 a while back and liked it a lot, but what I didn't like is if you put the motion in a scene to turn on the scene, then when it timed out it would turn off the scene and there was no way I could find to ignore it. So you are stuck with using programs to turn on scenes. Support told me this, and I could find a way to do this with the ISY. Do you know if it's possible with the ZSE40? What kind of battery life are you getting? I tried one of these as well and the accuracy of the battery level reporting. That's an amazing claim of 5 years battery life! Do they work in scene's and have the ability to ignore the off? I still love the speed of the old Insteon MS's but they are a little ugly, and having to make educated guess when battery will die is annoying, or hoping the low battery gets sent out and received...

The NS is dependent on both. If it detects an error when trying to send it sets an error condition on the node and for most errors it will retry. So, IMO, it is much more reliable than using email or NR from ISY. But, you can check that error status and send a notification another way if you like. I've considered trying to send an email when there is an error that looks to be an issue with the pushover service, but that won't happen for a while. Sent from my Pixel 6 Pro using Tapatalk

Currently you can only have one copy of the NS running on the same machine because it uses a hardcoded port number. I think I have an issue filed to fix this. Sent from my Pixel 6 Pro using Tapatalk

Yeah, the disappearing configuration info is a PG3 bug, hopefully will be fixed soon. Sent from my Pixel 6 Pro using Tapatalk

The order doesn't matter, only on or off must be last. Sent from my Pixel 6 Pro using Tapatalk

Set log to debug in PG3 UI, restart NS, open AC and if problem still exists download log package and PM that to me. Sent from my Pixel 6 Pro using Tapatalk

Did you close and reopen the AC? Sent from my Pixel 6 Pro using Tapatalk

That's weird. Please download log package and PM it to me Sent from my Pixel 6 Pro using Tapatalk

No, just need patience Wasn't able to check until just now, and re-uploaded and confirmed it is there.