bpwwer

So it worked. Looks like I didn't update the profile files so that's why the data field names don't match/make sense. To get the update: cd ~/.polygot/nodeservers/udi-wll-poly 'git pull origin master' It should grab the latest code from the repository Then from the admin console press the "Update Profile" button and it should update the field names. You might have to restart the admin console before it will see the changes.

What you typed above looks like there's an extra '/' character at the end but that shouldn't matter, it works for me both with and without that. Can open it with your browser? The error means bad request, but I don't see anything bad about it. It's the same command used by Polyglot so if you've been able to install any node servers it should just work. I'm sure you entered it correctly, but can you cut-n-paste the command or is that not something you can easily do with your configuration?

Does that mean you can't actually query it unless it's on Wi-Fi and the app is running? If so that's a strange bug. Have you actually tried pointing a browser at it? The docs I have say it should return current condition data at http://<it's ip address>/v1/current_conditions If you get data there, the the node server should work. You can install the node server with the following steps on your RPi. 1. cd ~/.polyglot/nodeservers 2. git clone https://github.com/bpaauwe/udi-wll-poly 3. from the polyglot web interface -> NodeServers -> Add NodeServer 4. select "WeatherLink" from the list of available node servers and add it. The only configuration is to add the IP address in the custom parameters. Once that is entered and saved, it should start doing queries every minute to get the current conditions. Log information will be in ~/.polyglot/nodeservers/udi-wll-poly/logs/debug.log

@garybixler I have a test version running using some sample data I was able find on-line so let me know when you get the hardware setup and I'll get you started on it. Right now it's just grabbing some of the current condition data and I've not tried to access the 2.5 second UDP data. Also, there are a lot of different wind / rain values available, I'm just pulling the basics so you'll have review them and see if there's anything else that would be useful. The node servers also have to be written properly to work this way too. I'm not sure all of mine are. But even so, some of the weather data, especially when it is coming from a local station, can vary slightly with every update. So something like 2.5 second wind speed/direction readings are very likely to change a lot unless it's a very calm day.

I see two different ways to access the data. 1) is by connecting locally to the a WLL device. With this method, current conditions can be polled fairly frequently (10 seconds) and it can also be set up to broadcast some data (wind and rain) every 2.5 seconds over UDP. This is what I was looking at using. With the initial version just polling for current conditions (probably at something more like 1 minute intervals just to not overwhelm the ISY). Setting it up to get the UDP broadcast would be dependent on use case requirements (I.E. do you see a need for that data at that interval?). It sounds like this is what you're looking for too. 2) is to connect to the WeatherLink server over the internet. The polling interval for this is much longer (15 minutes?). This also has a dependency on the internet. However, it could also be run from a cloud base Polyglot. Based on what I found, it sounds like they are updating the API for this method with the new API expected later this year. I'd rather postpone any work related to this until after the new API is releases, if something like this is desired. Do you have a local Polyglot set up? And if so, are you comfortable installing a node server from the command line?

Hi Gary, I don't believe anyone has created one yet, but from what I found searching on-line, it seems like it would be pretty similar to the WeatherFlow node server that I wrote. I don't think it would be too hard, but without direct access to a WL device, it can be a bit time consuming to debug issues getting getting it working. If you're willing to spend the time testing and providing feedback, I'll be happy to create one.

Did a bit more with the new module last night. I associated a Zooz water valve and it worked great. I then created a scene and controlled the value with an Insteon switch. I also re-oriented the ISY to vertical but still have issues communicating with my multi-sensor. The sensor is quite far from the ISY (and farther from any other z-wave device) but it did work well with the old module/external antenna combo.

Installed the board to day and no issues with the installation. Initially, there were some issues with both my Kwikset lock and Aeotec multi-sensor. A network heal seemed to clear up the problems with the lock. I ended up removing and re-associating the multi-sensor. And while the multi-sensor did re-associate, it still seems to be having issues. I suspect it is simply that the range isn't as good as I was using an external antenna with the old board.

Just so you're not feeling completely alone, I agree with you. In my HomeSeer plug-in, I track scene state and allow for state change events. I do it based on the Insteon definition of a scene which is a set of devices set to specific values. The ISY knows that information as my plug-in gets that info from the ISY. Then any time a device changes state, I check to see what scenes that devices is a member of and check each of those scenes to see if all the devices in the scene match the "scene definition". If they do, the scene is ON and if one or more don't, the scene is OFF. As far as I'm concerned, it doesn't really matter how the scene got turned on or off. I you went around and set each device manually to the values specified in the Insteon scene definition, then the scene is ON. But that's just my opinion. Not everyone has the same definition for what a "scene" is and thus we see many different interpretations of how to handle various cases and events. Because all of these different interpretations are neither wrong or right, UDI has no clear direction for how implement scene status/state. Seems like about once a year someone brings this up.

WeatherFlow is pretty open about access to the station data. They have a "hub" that collects the data from the sensors and then sends that data out over a number of different channels. One is via BLE to smartphone/tablets. It also sends the data via WiFi to WeatherFlow servers where it can be accessed via a published API and it sends it via WiFi to your local network as UDP packets (also well documented) so local applications can directly make use of it. I've created a node server application that takes that data and feeds it the ISY so that ISY programs can use it to control other things. For your application, the WeatherFlow station has a nice feature where it can send out "rapid wind" updates. These are sent every 3 seconds. With that you'd be able to detect gusts immediately and start rolling up the awning. There are other personal weather stations that could provide similar capabilities, but would likely require some development to get the same integration with the ISY. For example, I have an Acurite 5-n-1 system today with some additional hardware and a program I created, I have it simulating the WeatherFlow data to have it integrate with the ISY. Acurite is not nearly so open with their station data and one of the reasons I have a WeatherFlow station on order. The one downside to the WeatherFlow station is that today is the last day to pre-order it and you'd have to wait at least 30 days for it to ship.

Sure, to the rainmachine or nodelink? I won't be able to do it until a bit later tonight, but I can PM you the info.

And for some reason the last post lost more than half of what I wrote I logged the connection with my HS plug-in and get the following. You'll notice that the response from my HW version 1 box is different from what a newer box will return. Is is possible that your response parsing is failing on this? I know I had issues with it when trying to get my code working on a newer box. If you want me to try pre-release versions to help debug, let me know. RainMachine HW version: 1 SW version: 3.74 API: 3.64 Attempting to authenticate with https://192.168.92.56/api/4/auth/login Got response: {"statusCode": 0, "access_token":"NMAMFMCMPAAGAJMA", "expires_in":157680000 }

After a restart the error changes but still not working 2018-02-09 09:20:23 - ISY NodeLink Server v0.9.5 started 2018-02-09 09:20:23 - Web config server started (http://192.168.92.205:8090) 2018-02-09 09:20:23 - ISY resolved to 192.168.92.26 2018-02-09 09:20:23 - ISY Node Server config detected (profile 1) 2018-02-09 09:20:24 - Warning: nodesetup.zip file needs updating in ISY 2018-02-09 09:20:29 - RainMachine Login Error - The remote server returned an error: (400) Bad Request. [rain1]

With 0.9.5 it does accept the port number but now I get: 2018-02-08 15:22:00 - RainMachine Login Error - The underlying connection was closed: The connection was closed unexpectedly. [rain1] I don't know if this helps, but with my HS plug-in I'm connecting to: https://<ip>:443/api/4/auth/login and posting: { "pwd":"<passwrd>", "remember": 1 } I'm using C# and have to also handle the invalid certificate and force disable the Expect: 100-continue header to get authentication working. I believe my code works for later RM modes also although my sample size is very small (1 new generation RM)

Thanks! I'll give it a try later today.

With 0.9.4 I'm still having issues getting it to connect with my 1st gen. When I enter the ipaddress:port I'm getting a tooltip message that says "! Please match the requested format" I'm entering 192.168.92.56:443 so I'm not sure why that doesn't match the requested format. Am I missing something? If I go with just the IP address, it accepts it but I'm getting: 2018-02-07 17:06:52 - RainMachine Login Error - Unable to connect to the remote server [rain1] I know it's possible to connect and interact with my rainmachine with local authentication as I have a HomeSeer plug-in that works with it.

Nothing is wrong. A little background... A long time ago, when I added support for variables, I had the plug-in query for additional variable types thinking that UDI would add some additional types beyond the two integer types. By querying for other, not yet defined, types, I thought it would make the plug-in a bit more future proof. Recently, I tried to improve some of the error reporting and that improvement happens to catch the case where it queries for the undefined variable types and gets an error back. It's always done this, just now the message makes it sound more dire than it is. Every time I start the plug-in now, I think that I should fix that, but since it doesn't effect the operation, I've been putting it off. It will be fixed in the next release.

I don't think so. I had a computer attached and it always read -19w. I think it's still doing that, I haven't looked in quite a while.

I have one that did the same thing. I never did figure out why and have just ignored it for the past couple of years.

I welded the contacts of a couple of different X10 outlets the same way. I think I had one last for a handful of on/off cycles before it gave out. The current one has been in place for a few years now and I'm very surprised that it still works. I don't know what magic this particular brand uses but it seems to work. Now I'm not using the dust collector every day and not even every week, but it is a Oneida-Air cyclone unit and probably has a 1.5 HP motor. When this X10 outlet gives out I'll have to look at other solutions. Probably just get one of the remote kits designed for it since I don't really need this tied to the automation system.

I've been using an X10 relay outlet to turn my dust collector on/off for years. I don't remember what brand but I bought 3 or 4 different brands and did destroy a couple of them with the startup current draw. The nice thing about the X10 based outlets was that they were fairly inexpensive. I really didn't expect it to last this long. My dust collector is a fairly large cyclone unit on a dedicated 15 amp circuit. I was using an X10 mini remote and X10 transceiver, but the transceiver seems to have died so now I'm actually using the ISY via the admin console. I really need to get an Insteon remote and get it set up to replace the X10 mini remote. Having to go inside and fire up the admin console to turn the dust collector on/off is a bit of pain.

I've been using Insteon since the beginning. Failures have been minimal. Icon switch micro-switch failures (most covered under SmartHome's warrenty). One Icon switch failure (not micro-switch), one PLM failure (fixed by replacing caps), and a couple of early lamplinc failures. I do have two somewhat flakey keypadlincs. I don't have any whole house surge protection, no special filtering, etc. I don't treat the house any different because it has Insteon devices in it. I would guess that many devices are over 5 years old and probably a few that are over 10.

We have a fan with the same remote that's failed. I think it was something in the fan that failed though and not the remote. At this point I just hard wired the light so the wall switch controls that since we rarely used the fan anyway. I did find someone who had reverse engineered the wiring but I didn't experiment with the fan to see if I could get a FanLinc to interface with it. It was on the todo list but pretty low priority.

That's a bit misleading. HomeSeer can run on many different types of computers not just your desktop PC. In fact, HomeSeer also runs on a cigarette pack sized computer that has no moving parts and draws minimal power. See http://store.homeseer.com/store/HomeTrollerZee.aspx It can also run on server class hardware and on virtual machines. The ISY is fantastic for controlling Insteon (and increasingly Z-Wave) devices. It is also able to interface to other protocols and devices to some extent. But if you have other protocols or types of devices that you require solid interfaces to, then you'll probably need to look beyond the ISY to do that. If Insteon support is your primary goal (which it sounds like it is for the OP), then the ISY is the way to go. The good news is that if you do need to expand in the future, it's also possible to interface the ISY with a more general purpose, software based automation system so you get the best of both worlds.

No, you need to upgrade to the latest ISY firmware and re-configure the weather module. The ISY now uses HAMWeather instead of Weatherbug Yes, but it's no longer accessible. HAMWeather is getting personal station info via NOAA <- CWOP link and while I send data to CWOP I haven't been able to get registered with NOAA to get the data flowing. HAMWeather is adding another path in a few weeks and then my station should be accessible again.