bpwwer

@sjpbailey This really should be a new thread on Discord or a ticket as there are only a couple of people that can answer your questions and/or actually help you. All node servers require a license to install and run. The cost of the node server doesn't matter. So yes, once a user obtains a license for a node server they can't delete it. Only UDI can delete a license once it's been granted. Perhaps the name of the page is a little confusing as it's not really "Purchases" but a list of node server licenses associated with the user's account. You'll need to provide more information/diagnostic information to the one person who can debug this. I don't know if this post will get his attention or not. For me, every time I've used those functions they have worked as intended. There is, it's the "Delete" button on your "List my Node Servers" list. I don't really understand what you're saying here. If you want to create your own purchasing/licensing system then you can control refunds. But the current system was developed by and is managed by UDI so they control how refunds are issued. By submitting node servers to the UDI node server store, you're agreeing to allow them to manage the licensing. Not an unreasonable request. You should submit a feature request to UDI for this. You can. When you submit a node server to the store you have a drop down menu that lets you select which store you are submitting it to. If you edit the beta node server entry and then change it to submit to the production store, it puts the same node server into the production store with all the same purchase options. Users that installed beta versions can then re-install the production version using the same license. It is also possible to create limited life time beta versions that can only be used by users for a specific length of time before they expire. Once expired, the user then needs to obtain a new license for the production version. You can pretty much do anything you want. However, you do have to pay close attention to what you are doing as it's just as easy to mess things up.

Creating a node server specifically for the mini-splits probably wouldn't be less expensive, depends on if there might e more demand than just you. A quick search led me to the following docs. https://openapi.ing.carrier.com/Content/pdf/getting-started.pdf It also looks like there may be an HA integration available which would help. If you can verify that there's a published API that's accessible to third parties then you may be able to work out a deal with one of the node server developers to create a node server.

There isn't any way to hard code device IP's in the node server. It was designed to only do the network device discovery.

I think I fixed it, try 2.1.6

Yes, I ported it from PG2 to PG3 but don't have any devices and can't really provide much in terms of support for this node server.

There is no automated way to "migrate" a PG3x installation to another hardware device. The current PG3x backup process backs up hardware specific information. If that is restored to different hardware, it won't work without updating all of the hardware specific settings. At this time, there's no documented process to update that hardware specific information. My recommendation is to document the configuration of your node servers before hand. Then do all the IoX/z-wave migrations and get the eisy working for those. Then do the portal PG3x license migration. Lastly, install all the node servers** to the same slots and configure them using the information you collected originally. ** You may have to use the re-install option to do the install as PG3x probably thinks there is already a node server installed (from the IoX restore).

Did you restart the Admin Console after installing the node servers? The Admin Console only reads the node definition information when it starts so after a node server is installed and sends it's node definition information to the IoX, the Admin Console needs to restart in order to read it. From the screen shot, it looks like the Admin Console doesn't know how to display the nodes so it's just displaying random stuff. (looks like a lock device node is being displayed)

I believe the original author of the node server has abandoned it. I converted it from PG2 to a PG3 node server but I don't have the hardware to test or debug issues. The fact that it created the zone nodes is a good sign, that means it was able to connect to your account and pull data about the system. I took a quick look at the code and it looks like it is supposed to update the zone status at the "shortPoll" interval (which is in seconds. The default seems to be 2 minutes. Maybe I'm missing something, but looking through the code, I don't see any status called "Locked". Zone status looks like it should be one of OK Bypassed Faulted Troubled Tampered Failed Alarm Unknown With all node servers, it's best to check the log if you're having issues. In this case, I'd recommend that you do the following: Restart the node server Click the Log button to display the log Switch the log level to "Debug" Once the node server starts it should query your TotalConnect account for panel information and then query for information about each zone. After that, every 2 minutes it should query again for the zone info. If what's in the log doesn't make any sense to you, use the button to download the log and then send it to me in a PM.

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