residualimages

Can confirm install now allowed. Will keep you in the loop.

I see the Trial now vs Free/per 6 months, but still won't install. Mentioned this in the Discord too in case @bmercier can explain or assist.

So it seems like my old trial version expiring has really FUBAR'd the ability to install. I tried installing on same slot before uninstalling - no dice. I tried uninstalling and then reinstalling - no dice. Now I am working through a series of rebooting eISY / PG3x and holding my tongue on the left side of my mouth for my next attempts. Will report back. No dice.

The fact that it's on your network is good! SSH'ing into it is nice. (you can use CTRL+C to get out of the tail command) Are you getting advice in your ticket from UD staff? Did you say that you had tried this official way to update the IoX Launcher to re-include your device, since you have an IP address and it is online enough for SSH? I get the impression the auto-discover fails / cannot connect, and you tried the URL method (quote from here: I've cleared the Java cache, and reentered the URL into IoX in the correct format and no joy (the message says not found), but just to confirm... these exact steps did fail you? EDIT: Just realized @Mayben you posted the most recent reply, not @CoLong 😅 a) In ISY Launcher, click on the Add button b) Enter https://192.168.1.113:8443/desc into the dialog. c) Click on the OK button From https://wiki.universal-devices.com/Polisy:User_Guide#Troubleshooting: If the OS is below 13, you have a few choices: If your Polisy is more than 2 years old: You can purchase a brand new and updated SSD from here If you are a geek, you can reflash your SSD yourself. Please submit a ticket (note from residualimages: likely is basically the old Feb 2023 notes I mentioned in the end of my last post) If your Polisy is more than 1 and less than 2 years old Please ship to: Universal Devices c/o Reflash 5435 Balboa Blvd. Suite 205 Encino, CA 91316 Please make sure you include your return mailing address. If your Polisy is less than 1 year old, please submit a ticket and request for RMA

Did you try SSH'ing into the Polisy? @Geddy mentioned it in the Default Email Server thread, and it's a good idea to check if you have SSH access at a minimum. Open Command Line or Terminal: ssh admin@ipAddressOfPolisy Default password for the admin user under ssh is "admin" (note that it is not the same as Admin Console password, which you have likely changed). You can then use this command, again using the "admin" password, to see what updates are being attempted: sudo tail -f /var/udx/logs/log You can also use this if you have any PG3 Nodeservers / Plugins to see activity there, if present: sudo tail -f /var/polyglot/pg3/logs/pg3-current.log I once had an issue (Ticket #19880) where: It was resolved with re-imaging the device via @Michel Kohanim's instructions (note these may be very out of date, since this was back in February 2023). Also note, this would wipe your device, so proceed with caution if you do not have a backup handy -- there may be less destructive methods UD / Michel can help you navigate in the ticket you have open with them.

On my eISY (v5.8.0) with PG3x (3.2.21), the same parameter values worked, though I didn't see any Nodes until I manually clicked 'Discover'. Perhaps I was not patient enough and needn't have done so? I am reluctant to restart the Plugin for fear of the not-authenticated loop I got into on the Polisy (after initially seemingly getting good responses on that one). Anyways, on PG3x / eISY, the Plugin populated 14 Nodes, though the default name/address of each Node may be either human readable (the device name as assigned in various Nest/Google apps), or it may be a hash of some sort, from what I see. So far in testing, I see: Nest Hello (designated as DOORBELL [Camera]s) each have a single Driver: GV1 Driver (Camera Clip / URL Stream); in Admin Console they so far show as 0; in the UDMobile app, they show what presumably will be a video stream when notifications are received, but currently show "Stopped" Nest Learning Thermostat (designated as THERMOSTAT) has each of the following Drivers: Update: I am noticing that it does not seem to receive updates, and there is no Query button that I can see. I did try Discover again to see if the THERMOSTAT would update the Heat/Cool State, for instance, but no dice. Fan Mode (CLIFS) Heat/Cool State (CLIHCS) Relative Humidity (CLIHUM) Mode (CLIMD) Cool Setpoint (CLISPC) Heat Setpoint (CLISPH) Online (GV0) Fan Timer Timeout (GV1) Eco Mode (GV2) Ambient Temp (ST) Other devices (designated / detected as CAMERAs) do not have any Drivers at present, it seems.

Speaking to "test with IoX and PG3 and see what bugs ... we can identify" -- I am curious if there is a user error, or expectation of PG3 working but really need PG3x, somewhere in my setup process, or an actual bug. Setting the stage: I already had 3 separate projects (hitting the max limit) under "Google Device Access Console", so I reconfigured an existing one whenever steps for that were reached via your setup guide. Device used: Polisy v5.7.1 with PG3 v3.1.23 (specifically not PG3x, just to see) Plugin version first attempted: 0.1.3 [Beta] Note that in the logs below, I tried to redact various of the parameter values to <label>. Outcome: First install to slot 15 seemed to fail: [removed partial log for readability] Installed a second time and it succeeded (did not have the 're-install to slot' wording, but rather acted like a fresh install from non-production store: [removed partial log for readability] After that successful install, I set up the parameters as indicated, used the Authenticate button and selected the Structure and Devices, and appeared to get a good response: [removed partial log for readability] However, I was not getting any Nodes showing up in the PG3 console, not even after refreshing the page. I hit the Restart button in PG3, and the plugin upon restart cannot authenticate: [removed partial log for readability] If I then try to use the Authenticate button again in PG3, I get directed to a website that says: Can’t link to Nest SDM Plugin Please contact Nest SDM Plugin if the issue persists URL: https://nestservices.google.com/u/0/partnerconnections/<projectid>/auth?response_type=code&redirect_uri=https://my.isy.io/api/cloudlink/redirect&client_id=<clientid>-<oauthid>.apps.googleusercontent.com&state=662127ab639f575636ca88af&pli=1 I have since found, in GCP, under Privacy & Security, a new Cloud Data Processing Addendum which I reviewed and accepted. I also had a security alert on an Android device and I said "Yes this was me" on adding the SDM Plugin. Still no change in the plugin or the authentication page from PG3.

I have been out of town but returning and expecting to test this out soon.

Thanks! I'm curious to see how you do it, especially if the repo is public (or if you feel comfortable adding me to it), as my nascent UDI development efforts and GitHub familiarization proceed.

I set this up today too, and continued to get that 401 error even after confirming email and verifying API keys etc, until I set up the Billing Name / Address / Payment Method (I chose PayPal) within OpenWeatherMap by clicking the Subscribe button -- I immediately also set the limit to 1000 API calls a day (it defaults to 2000), so I will never be charged for it. Once I did that "Subscribe" (even though its going to be free), the 401 errors went away and I got data -- both in my web browser when calling the URLs directly with my API key, as well as within the Nodeserver.

Yes. Many many folks (myself included) have issues with polling eventually / sporadically locking up the Eagle (where no new polls generate a response). The "listen for the push" method is much more stable. There are two pieces. Make a server process that listens for, and responds to, UDP packets on the same network as the Rainforest Eagle. There is a somewhat redacted version of my Node / npm script below, as I've hastily deleted the lines which post to ISY variables through REST. Originally adapted from: https://community.openhab.org/t/new-binding-rainforest-eagle-200-local-binding/44448/73 -- that post also links to a perhaps more robust Listener API document. Configure the Eagle through Rainforest's portal to attempt to send to the local IP_address/path:port that is running the server process from #1. For step #1, it can be entirely basic: const express = require('express'); const http = require('http'); const app = express(); const bodyParser = require('body-parser'); const InstaneousDemandTimeLimit = 1000; const SummationTimeLimit = 1000; var LastInstantaneousDemandTimestamp = 0; var LastSummationTimestamp = 0; var LastInstantaneousDemandWh = 0; // Tell express to use the body-parser middleware and to not parse extended bodies app.use(bodyParser.urlencoded({ extended: false })) app.use(bodyParser.json()); // for parsing application/json // this one handles the Eagle 200 packets app.post('/eagle200', (req, res) => { if (req.body.body[0].dataType == 'InstantaneousDemand') { if (parseInt(req.body.body[0].timestamp) > (LastInstantaneousDemandTimestamp + InstaneousDemandTimeLimit)) { LastInstantaneousDemandTimestamp = parseInt(req.body.body[0].timestamp); LastInstantaneousDemandWh = req.body.body[0].data.demand*1000 console.log('Instantaneous Demand (in Watts): ' + LastInstantaneousDemandWh); console.log(' Instantaneous Timestamp: ' + req.body.body[0].timestamp); }); }; } if (req.body.body[0].dataType == 'CurrentSummation') { if (parseInt(req.body.body[0].timestamp) > (LastSummationTimestamp + SummationTimeLimit)) { LastSummationTimestamp = parseInt(req.body.body[0].timestamp); console.log('***Current Meter Read (Total kWh): ' + req.body.body[0].data.summationDelivered); console.log(req.body.body[0].data); }); }; } res.set('Content-Type', 'text/plain') res.send('Okay') }) // choose an unused port for this use: app.listen(xxxx)

Their documentation is a mess, but I've been using their Local API for years (first under via ISY with @tgutwin's PowerEYE, then my own Node.js based one since Polisy). Maybe this is what I used more? https://rainforestautomation.com/wp-content/uploads/2014/07/EAGLE-Uploader-API_06.pdf See also some decent walkthroughs here: https://community.hubitat.com/t/release-rainforest-eagle/38883

@bpwwer -- happy to help test anything with a revision or new NS. Eagle 3 is compatible with existing Eagle-200 APIs (both Cloud Poll and Local Push). In fact, one thing that keeps me from using your current NS is the fact that it's the Cloud version API and using Polling, from what I can tell, vs using the Rainforest's Local API (which is a push instead of a poll). Instead, since I haven't taken the time to make a local-API version of a NS in developer mode, I actually point to a non-UDI/Polisy/eISY Node.js server on my network, which then pushes updated variable values to variables on the Polisy. Resources: https://www.rainforestautomation.com/support/developer/ https://support.rainforestautomation.com/support/solutions/articles/66000480916-eagle-200-local-api-documentation https://community.openhab.org/t/new-binding-rainforest-eagle-200-local-binding/44448/81 https://community.home-assistant.io/t/custom-component-rainforest-eagle-200-local-meter-reader/110656/27?page=2 https://github.com/home-assistant/core/issues/85388 https://community.home-assistant.io/t/rainforest-eagle-3-installation/566347/6 https://flows.nodered.org/flow/f2e96859b597b2eba61d20aa784efd24

I've found this out because I do some duplication of devices from time to time via Bond's backup / restore, particularly with backing up an IR device on one Bridge and restoring on another Bridge. It seems like devices with the same IDs across multiple Bridges currently fail to be enumerated by the NS / plugin. The Bridge named Living Room - Left ***68 has 3 devices; it only shows 1, I believe, because the other two devices were restored from / have the same IDs as the "Right Table Lamp (RGB Column" and "Right Table Lamp (Uplight Portion)" devices under the Bridge named Living Room - Right ***40. Here you can see that the 1st and 3rd device on each of the Bridges is the same ID -- accounting, I think, for the behavior I see in the NS / plugin where Living Room - Left ***68 is missing the two devices shown (Also, device ID 1475068761b3a53e is already on yet a different Bridge, so that's why Living Room - Right ***40 only shows 2, instead of 3, devices, I am thinking. Hazards of having 5 different Bridges.) curl -H "BOND-Token: xxxxxxxxxxxxxxxx" -i http://a.b.c.d/v2/bridge --> {"name":"Living Room - Right ***40"...} curl -H "BOND-Token: xxxxxxxxxxxxxxxx" -i http://a.b.c.d/v2/devices --> {...,"2ca84fd8092bd8a2":...,"1475068761b3a53e":...,"da5a6c19104fa387":...} ========================================================================== curl -H "BOND-Token: yyyyyyyyyyyyyyyy" -i http://e.f.g.h/v2/bridge --> {"name":"Living Room - Left ***68"...} curl -H "BOND-Token: yyyyyyyyyyyyyyyy" -i http://e.f.g.h/v2/devices --> {...,"2ca84fd8092bd8a2":...,"e7a0dae4af78e1b0":...,"da5a6c19104fa387":...}

As an aside, a long time ago, before the Bond NS days (so we're talking Networking Resources), I had a long press (or was it double press) of an Insteon switch to start the dimming command via Bond API calls (from the ISY), just running continuously until a repeated long press (or double press) from Insteon was detected - then the ISY would send the 'stop transmitting' command. The ceiling fan I used this on would ramp up and down brightness in a cycle, and then would stop in less than 1 second from the time the Insteon KPL or switch was long pressed / double pressed to the time the Bond Bridge received the API command from ISY and executed the 'stop transmitting'. With that particular ceiling fan, the brightness steps were slow enough that the <1 second was effectively very very close to real-time, relatively speaking. Only rarely would I mistime the Insteon press and therefore not get the dim level I wanted. Just saying, the delay from Insteon -> IoX -> plugin (NS) -> Bond might not be as bad as you suspect. 🤔