bpwwer

@bcdavis75 Thanks! I don't see anything in the logs that you originally attached to the ticket so the next time it is in the "failed" state, please download the log package before re-starting it. Then PM me the package. For the log to be useful, it needs to be downloaded on the same day that the node server failed.

System dead after attempting upgrade, multiple power cycles have not helped. Submitting ticket.

Upgrading Polisy from 5.6.4 - Started upgrade and after a couple of minutes AC said reboot was required and then AC lost connection and all ssh sessions dropped. How long is the upgrade supposed to take? I'm at 30 minutes since the ssh sessions dropped and still can't reconnect with ssh or the AC.

Do you still have the ticket number? I'd like to take a look at it now that I'm maintaining that node server. Going into the failed state twice a week is definitely not normal. A lot of times, the node servers are written to handle normal behaviors, but don't handle unexpected issues very well. It may be that something external to the node server is causing a failure that it's just not designed to handle. It can be hard for developers to account for that when they don't see the same external issue. I've been trying to be better at this so if I can see why/where it's failing, maybe I can make it recover properly.

I don't think that has anything to do with PG3. You also upgraded the IoX firmware, did you read through the release notes for the various versions of firmware to see if there's something you're supposed to do either before or after upgrading? In general, neither the PG3 update or the firmware updates should cause the Admin Console to stop working. What version of Admin Console are you using (help -> about)? If it's older than the firmware version, it may not work correctly. You might need to clear the Java cache and/or get a new version of the IoX finder/launcher

That's a pretty old version of PG3. PG3 can store multiple usernames/password combinations. So if you simply added a new username/password, admin/admin would still exist as a valid combination.

Yes, each node server install on your IoX has a unique username/password. We don't want someone or something that's not supposed to send commands to the node server.

When the IoX sends a command to PG3x, it does so by sending an http request (as defined in the UDI Node Server REST API docs). PG3x does require a username/password for authentication. When PG3x creates the node server entry on the IoX, it provides it with a username and password. If that gets changed on the IoX, then PG3x fails to authenticate it which is what looks like is happening here. To fix this try: From the Admin Console go to the Node Servers -> Configure -> <slot number range for Kasa node server> -> Kasa menu and then click the Delete button. This will delete the node server configuration from the IoX Then re-install the Kasa node server using the PG3x re-install option from the Node Server Store -> Kasa -> Install, midway in the dialog box there should be an option to re-install to the same slot. The re-install option won't delete any of your existing configuration options and shouldn't impact any existing programs or scenes that use Kasa nodes. These two steps should refresh the node server configuration on the IoX and allow it to authenticate when sending commands to PG3x.

@Jimbo.Automates That error means that IoX sent a command but didn't get a response back within it's timeout period. Could be something in PG3 or could be the node server. Probably need to trace through both the PG3 log and node server log to determine why. This can also happen if the IoX is too busy and doesn't process the response in time. But I agree, that it's unlikely to be a node server issue. Does this happen when sending commands to any other node servers?

Seems like it can't find/detect the bridge ERROR hue:connect: Cannot find Hue Bridge Before that, it says get_ip_address: Connecting to discovery.meethue.com/ So my guess would be that it's not getting what it wants when it calls discovery.meethue.com. But I don't know anything about how this node server is supposed to work.

I don't know why it's failing either. Mine finishes with status 'done'. I think your best bet is to open a support ticket with UDI since this seems to be related to the system and not the node server.

As background, some of the Python packages that are required to use the Emporia Vue library aren't available pre-compiled for FreeBSD. So, when installing the node server, those Python packages have to be built from source. If they fail to build, then you get the error that the module can't be found when trying to run the node server. By default, the Polisy doesn't have the tools installed to compile these packages from source. The Install Dev. Packages should install the tools needed. I just re-installed the node server and it installed correctly and runs without error. The install process does keep a log of what happens while installing the Python modules. It's in the node server's directory. In your case /var/polyglot/pg3/ns/000db95edfb4_6/install.log. From the command line you can do sudo more /var/polyglot/pg3/ns/000db95edfb4_6/install.log to look through the log. Failures that show up there are going to be OS related, not node server related.

I've made a beta version of a node server that uses the V2 API available for initial testing/feedback. The version 2 API is very different from the version 1 API. It organizes the data differently and node server node organization changes to match the API. The node server first queries for the list of stations associated with your account. For each station it finds, it creates a "station" node. It then queries for the list of sensors and sensor data reported by each station. It creates a node for each sensor associated with the station. These nodes are grouped with the correct "station" node and are named based on sensor product name. Support for different Units is still missing in this beta release. For some data (rain for instance), the data is available in both US and Metric values, but for most, it seems to only be available in US units. Since this is a new node server, you can run it in parallel with the existing production DavisWeather node server.

Try this: From the Admin Console Configuration tab, press the "Install Dev. Packages" button. Give it a minute or two to install Re-install the Vue node server

Thanks! Hopefully I won't break it while fixing all the things I broke on the RNET side.

There are pros and cons to restarting PG3x often. If the node servers are having issues and not properly recovering from errors (which is really a bug in the node server), then restarting them may mask/hide the problem. However, it's always best to try and work with either the node server author or UDI to get the node server bugs resolved, that helps everyone. However, when PG3x starts, it has to start up all of the node servers which happens in a fairly short period of time. In most cases, the node servers then try to update all of their data so the IoX gets blasted with everything all at once. Depending on the node servers and number of node servers, this can overwhelm the IoX, possibly causing it to drop incoming connections. In some cases, this can cause more issues with the node servers. We've tried to minimize the start up issues, so normally this isn't a problem, but we've designed the system with the assumption that PG3x will typically only be restarted infrequently. Given the 119 node servers that are now available, I'm only running a few of them. But my Polisy was restarted for the first time in many many months about 3 days ago when we had a power outage that outlasted the battery backup.

The list of sources (and other names) in the config data is just a fixed size array of characters. Russound does not provide any documentation on what or how data is stored in the config data block. I've had to reverse engineer that my self. When the node server looks at the names, it just reads the characters from that fix size array until it sees a null (value 0) character or it hits the size limit. So if it's showing "SonosName6", that's what's in that field. There might be something in that config data that says it should only use the first 5 characters, but I don't know how to get that info from the config if it exist. Best I can offer is to make sure the fields are cleared out using the Russound config tool. The TCP error usually happens when a command is sent to the node server but the IoX times out waiting for a response. This will happen if 1) the node server isn't ready for the command or 2) the node server doesn't recognize the command The errors in the log seem to be related to timing again. It seems like the CAM is taking much longer to respond to command than my CAV does and thus, the node server is asking for stuff too quickly before the zones are fully configured. Looks like the source indexing is off by one. Version 2.1.3 fixes the source indexing and should delay some of the operations until the zone nodes are configured.

Actually, you do. I use IcedTea with Fedora Linux and have it configured to always open the console when I launch the Admin Console. I don't remember how I configured it to do that, but google probably knows. I seem to remember adjusting memory limits as well, but I'd need to google how to do that as well.

No, it only communicates with the server. The WeatherLink node server gets data directly from the console.

I'm not sure what's returned in the data request. It may be that the app is doing something with the data and you'd have to create programs on the ISY to mimic that behavior.

Should be fixed in 2.1.2 that's in the store now.

I've made a beta version of a node server that uses the V2 API available for initial testing/feedback. The version 2 API is very different from the version 1 API. It organizes the data differently and node server node organization changes to match the API. The node server first queries for the list of stations associated with your account. For each station it finds, it creates a "station" node. It then queries for the list of sensors and sensor data reported by each station. It creates a node for each sensor associated with the station. These nodes are grouped with the correct "station" node and are named based on sensor product name. Support for different Units is still missing in this beta release. For some data (rain for instance), the data is available in both US and Metric values, but for most, it seems to only be available in US units. Since this is a new node server, you can run it in parallel with the existing production WeatherLink node server.

Yes, comparing the times between your CAM and my CAV, your CAM is sending packets at a much slower rate. I suspect this is related to the baud rate setting. I'm using 19200. In your case, it was timing out while trying to get the config data which explains why most things didn't work. I've increased the timeout so it should work now. The downside to increasing the timeout is that it now takes more time to determine how many controllers are connected. As the only way to detect is a controller is to attempt to get the config data. If it times out trying to get the config data, then it assumes there isn't a controller at that controller ID. Version 2.1.1 has the increased timeout and is in the store now.

Based on what I'm seeing the log I'll have to do some investigation. It almost seems like the CAM is slower at providing the initial info than my CAV is and that's causing some issues.

Post here or PM, doesn't matter to me.