bpwwer

I also have an ISY at a cabin with no internet access and it is possible. Have you tried downloading the java app directly from the isy? http://<isy ip address>/admin.jnlp You should be able to run the downloaded admin.jnlp directly. It's been a while since I've had to access it so I'm not sure that's right. Also, can you get to the ISY by pointing your browser at the ip address? That should bring up a page that lets you control stuff, but you can't configure. It does have a link to the admin console, but I believe you have to have java enabled in the browser for that to work and most (all?) browsers have it disabled now.

Maybe a more simple way of putting this is that everything under the 'main' and 'program' tabs of the admin console can likely be migrated. Things under other tabs (like Elk or modules under config) will probably not be possible to migrate without manual intervention.

The issue with ISY modules is that they were written and designed before the concept of node servers so they're not manged the same as other "nodes". Their internal representation in the ISY firmware is different. So, yes, migrating from old ISY modules to new replacement node servers will likely always be a manual process.

No necessarily. There's really no reason why an Insteon node server would create nodes that are different from the nodes created by the current ISY firmware. Thus, it should be possible to use a backup of the ISY to recreate/restore the Insteon nodes using an Insteon node server. Scenes may be problematic. An ISY scene seems to be a superset of an Insteon scene/group and I don't know how those are linked in the current ISY firmware. I don't know if it will be easy to split them apart such that an ISY scene can be composed of components from different node servers. In general it should be possible to provide a migration path and I would hope that's being considered.

Not a dumb question. Today the ISY has an Insteon node server built in. It's a large part of the ISY firmware. The ISY also has a z-wave node server built in. You can think of an ISY as a couple of node servers with a node server framework and rule (programs) engine. For the Polisy, the idea is to separate the z-wave and Insteon node servers from the core framework/rules engine. A node server for Insteon would communicate with Insteon devices using the PLM. However, by making it a separate node server, it removes some of the restrictions imposed by the current hardware and it would be possible to use a USB PLM or maybe even the HUB for the device communication.

I'm just going to drop this here. Would UDI be willing to support an open source Insteon node server development project? With the existing group of node server developers, I'm sure there are a few of us that would be willing to contribute time/effort to developing a node server for Insteon. If UDI is willing to support the effort by providing existing nodedefs, etc. and possibly access to existing ISY Insteon code, that would provide a good starting point. I fully understand the issue that UDI has with Insteon. When it was new, I spent a lot of time trying to create a set of Insteon tools for Linux. I gave up when I found the ISY because UDI's effort was much farther along and a lot more stable than what I had working at the time. Developing for Insteon is painful, but, like others here, my house is using mostly Insteon so I'll likely devote some time/effort to supporting it, if only for my own use.

I'm sure there must be some way to have the loops on top of the floor and covered well enough to survive being driven over. My cars that are in the garage, rarely leave the garage, otherwise I'd think about experimenting with this.

A quick search found these https://www.amazon.com/Wal-front-Vehicle-Detector-Inductive/dp/B07K1BNL59/ref=psdc_7459508011_t1_B07H3N41H4 Not much info, but for ~$20 it might be worth playing with.

The node server does try to minimize the data sent to the ISY (and thus minimize the log entries) by only sending data when it has changed. But some weather data values do change frequently and the only way to change how often is to change the poll interval. This is one of the reasons I try to be somewhat selective in the weather data presented by the weather node servers. The more different values the node server tracks, the more data that has to be sent to the ISY.

Setting the log level to error should reduce the messages down to just error messages. Re-Discover causes the node server to review the nodes it's created. It will do this every time it start automatically and if you change the Forecast Days parameter as that's the only way to change the nodes it creates. Remove Notices will clear any notices the node server has displayed on the Polyglot dashboard-details screen. Update Profile will cause the node server to resend the profile files to the ISY. This also happens automatically when the node server is installed, but in some cases, the ISY is unable to accept the files (maybe it was too busy) so the option is there to resend them manually.

I just wanted to point out that it's not a requirement to have to Polisy's or RPi's to support two ISY's. The current ISY ecosystem wasn't really designed with the idea that there'd be multiple ISY's trying to co-exist with overlapping data sources. Some type of creative solution will likely be needed. For the Davis, that may mean feeding the data to something else first, that can support sending the data to multiple consumers.

You can run multiple instances of Polyglot on the same hardware. It does have environment variables that allow you to change the ports used by an instance of the program. I'm currently running both version 2 and an alpha of version 3 on my Polisy. If you wanted to install a second instance of Polyglot running on a Polisy, you'd have to set up the directory structure and port configuration so they don't conflict with each other. You can also run multiple copies of Polyglot on an RPi, though I've never tried that.

No not OpenHab, I just searched on github and npm for projects related to velux. The ones I found provide simple examples to create a program that uses the module to communicate with the KLF200. The first one I found on github looked like you could load it on an rPi via PIP and create a simple python program that used it. That's where I'd start just to get an idea on how to use the module. Maybe look at more than one and pick the one that works best. At this stage, not even trying to do any integration with ISY. We're still working to define the PG3 API's, but there's no expectation that existing PG2 node server will run as-is on PG3. How much effort will be needed to migrate a node server is still unknown.

it looks like there are both Python and node.js modules available that implement the API. I'd suggest looking over those and maybe experimenting with them first to understand better how to interact with the KLF200. Then you have to decide what information is important to both for display and commands. Use that to define what you want the nodes to look like on the admin console. From there you can create the profile files and start creating a node server from the template available. Based on what little I've looked at, the KLF200 is a controller that supports a number of different devices, that means creating nodes with status/commands for all the different supported devices so it sounds like a fairly complex node server. Another consideration at this point is that PG3 has just started alpha testing. It's not ready yet to start developing node servers for it, but it will be soon. It may not make sense to put in a lot of effort creating a new PG2 based node server and then more effort to convert it to PG3.

Someone else may be able to provide a better solution, but I believe you need to set a flag (variable) and use that to trigger the notification. Something like: if AQI > 100 then high_aqi = 1 else high_aqi = 0 and a second program if high_aqi = 1 then send notification The problem you're having is that every time the AQI changes, it triggers the if condition to re-evaluate. By using a variable, the variable only changes when the AQI goes over 100 or under 100.

If you weren't aware, the admin account used to ssh in and the admin account used for the web interface are different accounts. That's more of an FYI for anyone following this. Have you reloaded the web interface browser page? My system will get stuck where I can't log in, but as soon as I reload the page it lets me log in. Something seems to be cached on the browser that prevents it from properly authenticating. I'm now in the habit of always re-loading.

All of the valid values are in the documentation here: https://github.com/bpaauwe/udi-owm-poly/blob/master/README.md 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].BARPRES (current barometric pressure) sys.node.[address].WINDDIR (current wind direction ) sys.node.[address].DISTANC (current visibility) sys.node.[address].DEWPT (current dew point temperature) sys.node.[address].UV (current UV index) sys.node.[address].GV2 (current feels like temperature) sys.node.[address].GV4 (current wind speed) sys.node.[address].GV6 (current rain rate) sys.node.[address].GV7 (current snow rate) sys.node.[address].GV13 (current conditions) sys.node.[address].GV14 (current percent cloud coverage) sys.node.[address].GV18 (current percent chance of precipitation) Forecast node sys.node.[address].CLIHUM (forecasted humidity) sys.node.[address].BARPRES (forecasted barometric pressure) sys.node.[address].DEWPT (forecasted dew point temperature) sys.node.[address].UV (forecasted max UV index) 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].GV2 (forecasted daytime feels like temperature) sys.node.[address].GV13 (forecasted conditions) sys.node.[address].GV14 (forecasted percent cloud coverage) sys.node.[address].GV4 (forecasted wind speed) sys.node.[address].GV6 (forecasted rain) sys.node.[address].GV7 (forecasted snow) sys.node.[address].GV18 (forecasted percent chance of precipitation) sys.node.[address].GV20 (calculated ETo for the day) Your 'address' is n001_weather for current conditions so just substitute n001_weather for [address] above. For the forecast nodes, it's probably n001_forecast_0, n001_forecast_1, etc.

@PeterBarker11I'm assuming based on your post in the other thread that this is now working for you? In case anyone else sees this while looking for the solution. I believe this was resolved by restarting the admin console. When a new node server is installed, the admin console must be restarted before it can properly display the new nodes created by the node server.

My node server does pull data directly from the device, I'm using the V1 API and it can be configured to pull as often as you want. It currently does not handle multiple sensors, at least not correctly, so I'd have to make some modifications to handle additional outside temp/humidity sensors and I'd need to see what the data looks like to do that. From looking at the docs, it appears that the WLL device does support multiple sensors for the current conditions, but I'm not sure I'd bet my own $200 on that.

The node server doesn't support any extra sensors. It pulls data from the 'current' 'indoor', 'soil' sections of the data. It only pulls one temperature/humidity value from the 'current' section. I can add more values, but would need to see the actual data from WLL with the additional data as I don't have a Davis system.

Great post! I have something like this also. I look at window status via a DSC alarm and will turn off the AC if a window is open. I also won't turn on the fan if all windows are closed. I use a personal weather station to get the outside temperature and look at the diff between the inside and outside temp. When the outside is a few degrees below the inside it triggers a program that can turn the fan on if a window is open. It will also turn the fan off if the outside is close to or above the inside. When this was all working, I could open a window when the outside temperature was about equal to the inside and as soon as it cooled down outside enough, the fan would automatically come on. When it started warming up in the morning such that the outside temp started to reach the inside temp, it would shut the fan off. There have been times that it got so cold inside that the heat would come on when the windows were closed so I like your idea of shutting off the fan if it gets too cool inside. I just created a Purple Air node server that monitors air quality so I'd like to incorporate that too so that we don't run the fan if it's smokey outside. We've woken up at night to find the house smelling like smoke inside.

I had a whole house fan set up with a bunch of rules including indoor/outdoor temperature. At one point I got it stuck in a loop where it would turn on, blow some air over the HVAC thermostat which would cause an indoor temperature change which would turn off the fan. Once it stopped the temperature changed again and the fan would turn back on. Probably not good cycling the fan like that. It took some playing around with temperatures to get it working right. It was pretty cool when it did. I had it also tied to window state so when the indoor and outdoor temp was about the same I could open some windows and then when there was enough of a difference the fan would come on and start cooling things down. And if it ever got too cold inside, it would shut the fan off, or in the morning when it started getting too warm outside, it would shut the fan off so that we wouldn't pull warm air into the house. Basically all we had to do to control the fan was open/close windows.

All of the weather conditions are considered status. Control would be used for things that don't really have a current status. Something like a lightning strike event could be a control, but the distance to the strike is a status. But I haven't created any controls in the WeatherFlow node server. Any program that triggers on a status, will get executed when the status value changes. So yes, if you had something like: if temperature > 76 then turn on fan else turn off fan would cause the fan to turn on/off every time the changed going above/below that limit. To prevent that you either need to guard band the value I.E. have the on temperature > than the off temperature or add time references so that it has to be above or below the threshold for some amount of time before switching. The node server is getting updates from the WeatherFlow hub at 1 minute intervals so that does limit somewhat how often things can change.

File -> Set Userid/Password from the admin console.

That did it, both are showing up now, thanks!