Jimbo.Automates

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.

Need more time in the day not luck, day job kept me slammed today. Just uploaded again and confirmed it took.

Ok, sounds like my upload of the new version didn't go through completely. I'll check later. Sent from my Pixel 6 Pro using Tapatalk

Thanks for the logs! This was caused by a change to PG3. New version released.

PG3 Ecobee 3.0.1 NS released see the Release Notes

PG3 IFTTT Maker Webooks version 3.0.1 is released, see the Release Notes

Oops, guess I broke it and didn't re-test before releasing. I'll fix it tonight, but you can move it to the On event.

If it encounters an error the node status will show change. But IFTTT doesn't error out for things like misspelled trigger. Check the Nodeserver log and you should see it send the request to IFTTT? Sent from my Pixel 6 Pro using Tapatalk

That all looks good, yes the nodeaddress is what you want the node address to be in the ISY, the Node name is what you really se in the ISY so something like "Spotify Pause" would make sense. So each node it creates can have an "On" trigger and "Off" trigger, this is useful if it's something where on and off make sense. But you don't have to enter both. I would put your "Spotoff" in the On event name, then when you turn on the "Spotify Pause" node it will pause spotify.

Hey nice to see it may be useful for someone else! On the configuration page where you added your API Key should see these instructions: https://github.com/UniversalDevicesInc-PG3/udi-poly-IFTTT-Webhooks/blob/master/CONFIGURATION.md Although there is bug in bug in PG3 where sometimes doesn't show the configuration documentation. Hopefully those instructions clear it up?

This release brings a big change that makes using the REST option for the Notification Nodeserver much easer: The addition of: - Network resources malformed when using URL encoding. Follow these instructions${sys.node.#.name:url} - URL encodes the resulting string${sys.node.#.name:std} - Does standard formatting (as done currently)${sys.node.#.name} – Does default formatting (currently same as using “:std”) Now allows to create a Notification where the subject contains any node or program name, so you can use this in the path: /send?node=po_dev&monospace=1&device=2&Subject=node:${sys.node.#.name:url}+program:${sys.program.#.name:url} Even when the program contains spaces or other characters that would cause problems. Now one network resource can be used for multiple notifications with different subjects - Jim