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. 🤔

Aeotec SmartThings Multipurpose Sensor - Zigbee - Door and Window Sensor, Temperature Sensor US Model: GP-AEOMPSUS https://aeotec.com/products/aeotec-multipurpose-sensor/ https://aeotec.freshdesk.com/support/solutions/articles/6000242294-aeotec-multipurpose-sensor-technical-specifications Sensors: Open/Close, Temperature, Vibration What can help the @Administrator group? I have it paired, it just doesn't have any updates / data. X-ray details from IoX available if helpful.

I'm on OS of 13.2-release-p1 (I checked after Michel's post, though I already had upgraded to IOX 5.7.0. PG3 at 3.1.23.) I still have intermittent issues with all programs disabling after some reboots, even after doing some of the ssh file move/fresh create that was suggested earlier. I have since taken the advice of folks in the forum and named the "always disabled" programs uniquely. I chose "* " prefix to sort easily in the detail view, and I select all but those, right click and enable whenever I get a rebootGremlinOfDisabling. 🤷‍♂️

@Panda88 - are you the same user as just posted in the Home Assistant thread? If so, please help me out by letting me know what you have with your SPAN install, and if you have Polisy or eisy. 🙂

Just asking the community if anyone else has ventured into the SPAN Smart Panel world, as I have. I could use some feedback about your setups to make sure I'm ready for at least a non-production store beta of the nodeserver I am developing for PG3 / PG3x. The SPAN Smart Panel nodeserver will show SPAN Panel (1+), SPAN Circuit (1+ per Panel), and Breaker (all 32 physical slots per Panel) level details of status (including current Watts), and allow use in IoX programs and notifications. Circuits will also have the ability to toggle on / off as far as the SPAN is concerned, including as commands within IoX programs. (I'll repeat the disclaimer, as SPAN and their app already warn you, that relying on the software level 'off' for a Circuit before working on electric circuits is not officially appropriate.) The Circuits *should* have the ability to change the Priority as far as the SPAN is concerned, but I have not had much luck actually having the API calls be honored. It may just be my current lack of battery integration, though. The nodeserver is built to leverage *local* network control via SPAN's API, which they have been working with the Home Assistant community to gauge interest in, and gain feedback about, community use cases. I'd therefore consider the local API to be semi-official, but prone to changes over time. Image is from a work-in-progress build:

It would be like this; note that I have several BOND Bridges / SBB Devices, so I list each one in order separated by ";". If you only have one Bridge, you'll have one entry in the hostname parameter, and one entry in the token parameter:

Hmmm. Interesting. Future ideas as the renovation continues at my home.

Just to chime in - also all programs disabled after update from 5.6.3 to 5.7.0. @Michel Kohanim - do you want each of us to submit a ticket for this issue? Seems common.

Newly installed this NS last week. I do not think I've ever seen the Network Resources as anything other than '0', but that is not accurate. I have ~187 Network Resources; here's a quick snippet of some of those so you don't have to take my word: When looking at the NS log (just in default 'Warning' level), I see Network Resources constantly as an error; I went ahead and restarted the NS to get a piece of the log before the restart (showing the existing / recurring Network Resources error, the restart, and the re-emergence of the Network Resources error again): 2023-08-30 19:45:16 error: NS: processNetworkResources Error 2023-08-30 19:45:37 warn: POLY: Received stop message 2023-08-30 19:45:45 info: NS: Starting Node Server 2023-08-30 19:45:45 info: POLY: Interface starting 2023-08-30 19:45:45 info: POLY: Getting config from environment 2023-08-30 19:45:45 info: POLY: MQTT client connected 2023-08-30 19:45:45 info: NS: MQTT Connection started 2023-08-30 19:45:45 error: POLY: Config has logLevel: WARNING 2023-08-30 19:45:45 warn: POLY: Loglevel: warn 2023-08-30 19:46:10 error: NS: processNetworkResources Error If I put it into Debug level, and hit Discover, the log looks more like this: 2023-08-30 19:52:11 debug: NS: Message Received: { discover: {} } 2023-08-30 19:52:11 debug: NS: Discover Nodes 2023-08-30 19:52:11 info: NS: Discovering Nodes 2023-08-30 19:52:14 debug: NS: Discover Integer Vars 2023-08-30 19:52:16 debug: NS: Discover State Vars 2023-08-30 19:52:18 debug: NS: Discover Programs 2023-08-30 19:52:20 debug: NS: Discover Network Resources 2023-08-30 19:52:22 debug: NS: Discover Error Log Entries 2023-08-30 19:52:26 info: NS: Checking node: 4C ... ... 2023-08-30 19:52:26 info: NS: Checking node: n001_zzfk93868 2023-08-30 19:52:35 error: NS: processNetworkResources Error 2023-08-30 19:52:37 info: POLY: Setting node controller driver GV10: ...

UD Mobile shows only the numeric value, not the UOM string. I know that we say IoX these days, but the original experience / pain point was , and is still, present on my ISY994i too, of course.