Goose66

I upgraded my Polisy from PG3 to PG3x last night and everything migrated successfully (after an arbitrary number of reboots) and is running except HoneywellHome node server. The node server appears to be running with an increasing "Uptime," but the Current Status is "Disconnected." The log file is from yesterday and shows the node server running properly all day and the graceful shutdown last night when the upgrade was started. Stopping and re-starting the node server does not produce a new log file or change the Current Status from "Disconnected." Whenever I restart the node server, I get the following in the PG3(x) log file: 9/29/2023, 05:56:31 [pg3] info: startNs:: Starting HoneywellHome 9/29/2023, 05:56:31 [pg3] info: call_udx: Making request to socket with url /rest/pg3.start.ns 9/29/2023, 05:56:31 [pg3] info: startNs:: HoneywellHome starting polls 9/29/2023, 05:56:31 [pg3] info: Starting HoneywellHome Info timer 0 9/29/2023, 05:56:31 [pg3] info: startNs:: HoneywellHome updating database (enabled, timestarted) 9/29/2023, 05:56:31 [pg3] info: startNs:: HoneywellHome started. There is nothing else in the PG3(x) indicating any problems with the HoneywellHome node server. The IoX Admin Console shows all blank entries. Is there any known incompatibility of this node server with PG3x? Anybody else running HoneywellHome on PG3x?

You need one Custom Configuration Parameter with a key “hostname” and a value of the IP address, and another Custom Configuration Parameter with a key of “token” and a value of the token string.

The Discovery no longer works on PG3 or PG3x. UDI added the Zeroconf package (aka "Bonjour") into the standard build and starts it with the Polisy/eISY firmware in order to get it to respond to polisy.local. The downside of that is the node server can no longer start it's own Zeroconf listener for device discovery. There is a feature added to some version of PG3x that allows the node server to do discovery through PG3x, but I don't know what version that is and how widespread it is, so I haven't changed the code yet. In the meantime, just add the "hostname" Custom Configuration Parameter with the hostname or IP address of your Bond bridge, and the "token" Custom Configuration Parameter with the token value from the Bond app, and then the Discovery process will locate the bridge and create nodes for all of the devices. If you have multiple Bond bridges or SBB devices, you can add values for each of them to the respective "hostname" and "token" Custom Configuration Parameters separated by semicolons. Just make sure the hostnames and tokens are listed in the same order.:)

My concern at this point if I still had a 994 would be the SD card. I went through at least one SD card failure on my 994 and was dependent on UD support to get it back running. Especially since you are “starting from scratch” I would take this opportunity to upgrade to eISY and know you have support for the next 10+’years.

Have you tried Network Resources? Can you flash it with Tasmota and use the MQTT node server?

I imagine the thought is generally if there’s been any adjustments to outside lights other that “all off” then leave them alone.

I do want to point out that, while I completely agree there is a basic flaw in the program's design, this flaw you point out will not prevent the remaining lights from turning on after turning on the 'Entry Front Door Light', as may be interpreted from your post. That is because there is no WAIT or REPEAT statement in the running program that makes the program "re-entrant," thus once the Then branch of the program starts running, it will run to completion. If it were me, I would have a first, enabled program that had the "'Area 1 / FRONT.DOOR' is switched On" condition and a second, disabled program that had the remaining conditions and the commands from the Then statement. The "Then" branch of the first program runs the "If" branch of the second program. But neither using a variable to track the light nor structuring your programs with the "two-program" methodology (discussed ad nauseum in these forums) would appear to solve your problem of the program seemingly ignoring the sunset to sunrise condition.

I think (or hope) that it was just unfortunate timing. This is only a warning, and the node server will retry the connection every long-poll interval (default 60 seconds) until it is reconnected.

So you weren't getting the same 403 error that was present in the original issue. You are getting "HTTPSConnectionPool(host='partner-identity.myq-cloud.com', port=443): Read timed out. (read timeout=12.05)" error. This generally means either your network is down or the partner oAuth server is down or busy. What's more, after upgrading to 3.2.22, it appears (from your log file) it only tried four times (over 4 minutes) before the node server was shut down. Try starting it again and seeing if it can connect now.

The node server can only have one sub-level. I keep all my node server service nodes in one "Node Server" folder, and the garage door openers in a "Perimeter" folder. Alternatively, you can just move them all under a "Garage Door" or "MyQ" folder.

Go ahead an DM me your log file.

You may need to refresh your Node Server Store. Yes, there usually is an "Update" button on the node server details page when an update is available for a node server.

Ok, try again. I had changed the "edition" of the node server from "Free" to "Standard" thinking I was fixing an error, but when I saw your screenprint it occurred to me that it may mean people can't update. @drprm1 Since your Update worked, please check that you weren't charged for it. If you were, I will work with @Michel Kohanim to arrange a refund.

Crap. That shouldn't be "Purchase," it should be "Update." Let me look again.

Try refreshing your Node Server Store. I was able to update it on my production Polisy in my home.

I have uploaded a new version of the MyQ Node Server (v3.2.22) to the Node Server Store. This version adds a User-Agent header to the oAuth calls as well as the API calls to get around the 403 unauthorized values. It also adds a new driver value for the MyQ Service node that is a Node Server Status value managed by PG3. See release notes at https://github.com/Goose66/NSDocs/blob/main/myq-pg3.md for more info.

While I lost remote connectivity to my Polisy, the reboot was evidently successful, PG3 and the MyQ node server restarted, and the MyQ node server ran for three days without any 403 errors or other authentication or connectivity problems. It also restarted successfully tonight when I got back to my development box. So I have uploaded new v3.2.22 of the node server that should take care of the User-Agent issue for now. I note that there is still conversations over on the arraylabs/pymq Github repository regarding folks still having problems in HA, so I will keep an eye on it. Also, the User-Agent value is user configurable in this version, but I didn't put any references in the instructions or release notes to that. Let's keep that under wraps until we need it. There is a new version of PG3x coming out that should have a way for me to change the User-Agent and potentially other auth values (e.g., application key) remotely across all installed node servers, so maybe that will be out and in widespread use before we need to mess with all this again. Thanks for your patience.

Sorry guys. I had it all (at least mostly) working and but now PG3 has completely died. Cannot get to the UI or IoX on my Polisy. Restarting the Polisy remotely did not help. And since I am remote, my options are rather limited. I will be back local on Sunday evening, and I can look at it then.

I thought about that, but the problem is that if a specific value was required to work, we would have to communicate with every user on how to add it to their installation, and then if the value was required to change to a different value (or, say, needed to be randomized) then we would have to both roll out a new version and communicate to every user that they needed to remove any value they currently have configured. That said, I thought I had found a way to update the value used in the Node Server Store and then have all the installed node servers pick up the value on restart, but it looks like it won't work as I expected. If that is indeed the case, I guess a Custom Configuration Parameter settable by each user might be the best available choice.

I have added User-Agent headers to both the oAuth calls and the REST API calls and it is working. I am in the east, but I’m not exactly sure how the load balancing works or if your geographical region has anything to do with. The oAuth servers are a partner company and not Chamberlain. The concern is that Chamberlain will start using the User-Agent to block particular integrations, so I am adding a facility to allow me to simply change the User-Agent value on the fly without needing a new version of the node server to be packaged and uploaded. Should be done and released in version 3.2.22 tonight.

I saw the conversation on the pymyq GitHub repository today about the changes. Unfortunately I am traveling until Wednesday, but should be able to look at it then.

Ok, let me see if it may be the phase out of older API calls. This happens every year-and-a-half or so. UPDATE: While it could be just a problem with the oAuth servers (a partner to Chamberlain), it looks to me like they have changed access parameters, either the client secret or something else. As I have mentioned, I built this integration based on another integration that exists out there that I couldn't use directly. So I have no way of hacking the mobile app to see what has changed in the authorization structure and instead will have to wait and see what others find. Unfortunately not seeing other integrations having specific issues reported yet, and my mobile app is still working. I will continue to investigate. If you don't restart the node server, your node server may continue to operate for some time. Also, merged the two threads.

To add to @tazman's guess, if this is an overhead light, then it is very likely that the 14-2 romex coming into the top of the left box is your load, and the 14-2 romex coming into the bottom of the left box is your line. But always better to check with a voltage tester. As he said, in the left-box, conenct all the whites together and connect the black from the 14-2 romex in the bottom, the black from the 14-3 romex in the bottom, and the black (line) from the switch together. Connect the red wire (load) from the switch to the black from the 14-2 romex coming from the top. In the right box you have black (line) and white (neutral) from the keypad to black and white, respectively, from the 14-3 romex. The red (traveler) for the 14-3 romex is capped in both boxes. Again, always best to test and know what your line (hot) is, but if you end up guessing wrong which 14-2 romex in the left box is the line and which is the load, it could fry your switch, but I would think the more likely result would be that neither the switch nor the keypad would operate (no LEDs illuminated or long beep), and you could turn off the breaker and swap them out.

I'm pretty sure the OP said he was switching the 120V input to the transformer. Switching a transformer on and off rapidly can damage the transformer if it's cheap. I suggest switching the 12V down stream of the transformer. The lights can take the rapid on and off 12V - they have a solid-state power supply.

I wouldn’t worry about the Zwave switch as much as the 12v transformer.