bpwwer

The MagicHome node server currently in the non-production node server store uses flux-led so would probably work.

Just for reference, there are PG3 node servers for other inverters already so it's certainly possible to create one for Sol-Ark. I believe all the existing node servers get data either from the inverter's cloud service or locally over the network. I'm not aware of any node servers that use an rs-232/USB link. You can use a USB hub with Policy if you need more than the 2 available ports. One issue will be that I don't believe node servers have permissions to access the USB ports so that's something that would need to be worked out with UDI to modify the Polisy configuration to allow that.

@johnnytYes, confirmed. PG3 supports installing the same node server multiple times and to multiple ISY's. Once you have purchased a license, it is tied the Polisy PG3 is running on. You can then install that node server as many times as you want, on to any ISY that that PG3 is connected to. You could potentially delete PG3 and all it's configuration from the Polisy, re-install it and the license will still be valid. What you can't do, is use that license on a different Polisy (hardware box). The reason the "Target ISY" is shown in the screen shot above is because that dialog box is used for both the purchase and install and when you install, you do so to a specific ISY.

I just changed my password about 5 times without any issues. If it's a database issue, it should show an error in the PG3 log.

Nothing in that log file indicates there's a problem. However, there are restrictions on what characters can be used for node names. It looks like that's the only node that has an '&' in the name so you might want to try removing that.

Plant type is a variable used in the evapotranspiration (ETo) calculation. There are different values for different types of vegetation. 0.26 is a common value for residential environments. You'd have to lookup details on the calculation for more information.

@Michel KohanimIs this something you can do?

Where are you seeing that those node substitution variables should exist on the AERIS node server? Oh, never mind I see, the PG2 version README is displayed from the store link instead of the PG3 version. I've fixed that. The supported substitutions are: ### Current condition node * sys.node.[address].ST (Node sever online) * sys.node.[address].CLITEMP (current temperature) * sys.node.[address].CLIHUM (current humidity) * sys.node.[address].DEWPT (current dew point) * sys.node.[address].BARPRES (current barometric pressure) * sys.node.[address].SPEED (current wind speed) * sys.node.[address].WINDDIR (current wind direction ) * sys.node.[address].DISTANC (current visibility) * sys.node.[address].SOLRAD (current solar radiation) * sys.node.[address].UV (current uv index) * sys.node.[address].GUST (current gust speed) * sys.node.[address].PRECIP (current precipitation accumulation) * sys.node.[address].HEATIX (current heat index temperature) * sys.node.[address].WINDCH (current wind chill temperature) * sys.node.[address].GV2 (current feels like temperature) * sys.node.[address].GV11 (current condition coverage) * sys.node.[address].GV12 (current intensity of conditions) * sys.node.[address].GV13 (current weather conditions) * sys.node.[address].GV14 (current percent cloud coverage) * sys.node.[address].GV15 (current snow depth) ### Forecast node * sys.node.[address].CLIHUM (forecasted humidity) * sys.node.[address].BARPRES (forecasted barometric pressure) * sys.node.[address].UV (forecasted max UV index) * sys.node.[address].SPEED (forecasted wind speed) * sys.node.[address].GUST (forecasted gust speed) * sys.node.[address].PRECIP (forecasted precipitation) * sys.node.[address].POP (forecasted precent chance of precipitation) * sys.node.[address].ETO (calculated ETo for the day) * sys.node.[address].GV19 (day of week forecast is for) * sys.node.[address].GV0 (forecasted high temperature) * sys.node.[address].GV1 (forecasted low temperature) * sys.node.[address].GV7 (forecasted max wind speed) * sys.node.[address].GV8 (forecasted min wind speed) * sys.node.[address].GV11 (forecasted condition coverage) * sys.node.[address].GV12 (forecasted intensity of conditions) * sys.node.[address].GV13 (forecasted weather conditions) * sys.node.[address].GV14 (forecasted percent cloud coverage) * sys.node.[address].GV15 (forecasted snowfall)

The existing ISYInsteon plug-in on HomeSeer should work fine with an ISY on Polisy. From an external communication perspective, they are supposed to be the same. Note however that I have not tested that combination.

There must have been a typo in that URL. I've fixed it so it now points to the correct place. No, it does not work with a Tempest weather station. The WeatherFlow node server is specifically for the WeatherFlow Tempest, Air and Sky weather devices.

If it's not in the PG3 store with the same name (and it's now ST-Inventory instead of ISY-Inventory) or if you don't have a license for the PG3 version, it will skip trying to restore that slot from the PG2 backup.

The process for PG3 are a bit different, but it's mainly just in how you initially deploy your node server. Developers get access to a "Local" store in PG3 where you can add/remove node server. Once added, the process is a fairly simple install/delete or stop/start depending on how you get the changes to the node server directory. The Polisy supports both NFS and SMB file sharing protocols so it is possible to mount the Polisy's file system to another machine and then edit/copy files as if they were local. There are developers on slack that do this and can help with the setup.

This is what the AERIS documentation says:

Keep in mind that for PG3, the node server license is tied to the hardware. If you try to restore to new hardware, you won't be able to run any of the non-free node servers.

Looks like the node server store entry was messed up. Refresh the store then delete and re-install. It should show all the config parameters.

What do the logs say?

@seacordeanWelcome to node server development. Most of the node server developers are on Slack. That's the best place to ask questions and get answers. You do need to register as a developer with UDI if you have not to get an invitation. PG2 is being deprecated and support is slowly going away. It's find for getting a basic understanding of how node servers work so what you've done isn't wasted time. However, most node servers have been ported to PG3 and most new node server development is happening on PG3. I'm not sure why PyCharm thinks the processor matters. Do they run a component on the client machine? That still may be a problem as the Polisy used FreeBSD as it's operation system. Polisy is an X86 (or really an AMD64) processor. I can't really help you with IDE questions as I just use VIM on the Polisy to do all my development.

How do you feel about generating an API key for me so I see what the API returns and how it works. Blindly making changes to the node server and having you test and report isn't very efficient. I won't intentionally mess with the controls, I mainly want to see the data in the get queries.

Yes, "temperatureUnit" is either "F" or "C" according to something I saw in the API docs. The editor should have two ranges, one for each unit along with the matching UOM. What I find strange is that the targetTemperature (which also doesn't use the correct UOM in the editor) is reported in "F" but is being set in "C" The API isn't real clear on how the API knows which units to use when reporting temperatures. Does the device itself have the ability to specify which units you want it to use?

I can see where that is confusing. The code is also pretty confusing as it doesn't really deal with temperature units at all.

Sorry, made a error in the code. Try version 2.0.2.

Thanks! I believe I've fixed the problem. Refresh the node server store and you should see version 2.0.1 Then restart the node server and it should install the new version. If it still doesn't work, send me a new log.

If no one wants to maintain it, we'll probably have to pull it from the store, or maybe just move it to the non-production store so someone could work on debugging it if they desire. I took a quick look at it and it seems like one of the dependencies isn't installing. This is not uncommon as many of the Python modules are written for Linux and don't include packages specifically for FreeBSD. Sometimes they'll build without any issues on FreeBSD, other times they don't. In this case the build is failing. I didn't dig into why it was failing.

It should be exactly the same as the PG2 version in terms of functionality. If it's not working, please provide logs.

If you restart the node server does it then correctly display the status? After I install the node server it shows disconnected until I restart the node server. This appears to be a race condition within PG3 as it sets the correct (connected) status and then a few seconds later sets it back to disconnected. I think this may be happening for a lot of node servers but may be random depending on the how things get executed in the node server. I'll open a PG3 issue for this.