bpwwer

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.

Congratulations UDI team! Wining this grant provides some tangible reward for all the great work you do.

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.

These are great examples. Years ago I used MainLobby and Charmed Quirk. Recently I have investigated HS Touch. Correct me if I am wrong, aren't these GUIs primarily for other products, especially HS Touch, which have SOME ability to integrate with ISY, VS GUIs we can use to serve as the full ISY GUI? For me, I could likely live with HS Touch if I could buy only that and use it to FULLY control ISY.. However, I believe I would need the full homeseer and then get at ISY via Homeseer. That is very roundabout. Isn't this fundamentally the same with MainLobby? Yes, HSTouch is just the GUI interface to HomeSeer so you need the whole package to do anything. These are full fledged home automation software packages. They provide solutions that anyone can purchase and create systems that rival those from Creston and Control4. With Creston and Control4 the installer does all the programming and integration. Almost everything with a HA software package is an "add-on". You purchase only the components you need. This is how they keep the price somewhat reasonable. (this is a generalization, what's included with each package varies). I've created an ISY "add-on"/plug-in for HomeSeer, Elve, and MainLobby. The MainLobby plug-in is for an older version of MainLobby and I believe Cinemar has created one themselves for the most recent version. One of the design choices I made early on was to not support ISY administrative functions. So if by limited integration you mean you can't administer the ISY, then yes, limited integration. I think it's pretty important to separate out the administrative functions from the general day-to-day end user functions of the automation system. It's probably worth enumerating what I consider administrative functions: 1) Create/Edit programs 2) Add/Remove devices (including adding/removing to scenes/folders) 3) ISY configuration (Ex: NTP time, Location, etc.) 4) Module configuration (Ex: set weatherbug station / polling time, etc.) These are things that are normally done once or very infrequently (at least in my case) and the existing ISY console works well for performing these task. The HomeSeer plug-in is the most complete and the only non-administrative capability not supported by it is the ELK module, some of the recent z-wave work and things like portal integration. Z-wave device support for the plug-in is in development. Yes, you would need a full version of HomeSeer. But it's not really any more roundabout than running something like MobliLinc on Android. The main difference is that HomeSeer adds an abstraction layer between the GUI elements and the device interface so that it can support user designed GUI's. In my opinion, the more flexibility you want for the GUI, the more abstraction you need to add between it and the device. It would be very hard to justify writing a GUI designer and client like HSTouch but then limit it to only talk directly to the ISY. As soon as you add one device that the ISY can't control, you'll need to replace it with a more generic solution. Now I'm not trying to discourage Mike from investigating something like this, just trying to help clarify what's important. I'm currently using Elve and it interfaces to not only the ISY, but a Russound whole house audio system, a DCS alarm panel, a couple of Roku media streamers, and a custom whole house energy monitor system. No, I've only developed the ISY plug-in for HomeSeer. But I am interested in pretty much anything that interfaces to the ISY.

Hi NHWA, I think I kind of agree with you, but I'm not sure that we need something new to do this. Isn't this mostly available via the various home automation software packages, at the ones that have ISY support? Sure you have to configure the HA software and work out your touch screen designs but I don't think any system is going to automagically do that for you. With Creston & Control4 you're paying for someone to do that for you. I know HomeSeer HSTouch works with the ISY since I developed that. Cinemar's MainLobby product has some ISY support (in addition to the plug-in I write for it years ago), the now defunct CodeCore Technologies Elve has support, I believe Charmed Quark CQC has support. There's probably a few others that I'm not aware of. All of those will allow you to create a pretty tablet UI that interacts with the ISY. Now, I'm not sure anyone has created good UI's with these products that incorporate control via the ISY and made them available as a reference. GUI layout and design is not something I feel I'm good at. I'm really curious to know what you think is missing given the above software packages? Would you like a package that does all the GUI elements that the above HA products do but only interface with the ISY? Are you thinking it should be a tablet based product that allows custom GUI design and interfaces only with the ISY? Given that you mention high end automation products there's quite a spectrum that exist between what's available today via the ISY's web interface and those products. I think I'd be more interested in seeing someone take an existing product that interfaces with the ISY and create a well designed GUI with it. Just seeing a well thought out and designed system can provide a lot of inspiration.

I've been out of town for this last bit of rain, but it looks like everything worked, the monthly total seemed to increase by the right amount. I do have an annoying issue with my program crashing after 4-8 days which makes it hard to track down. I need to put some additional effort into getting that fixed.

Yeah, it was raining. I accidentally stopped my program. I've been trying to get monthly & yearly rain values working and failed to restart the program after making a small change before I left for the day. So totally my fault. Looks like we had about .71 in. total.

I have the costco version of that (01050C), but it's the same components. They only make one bridge and one 5-n-1 sensor. There's a number of different displays. I'm not real happy with that display but then I didn't buy the package for the display so never really used it. On sale, that is a pretty good deal. Initially, they had a big problem with the humidity sensors, I've had 3 of the 5-n-1 sensors before getting one that works correctly. The bridge is supposed to be plug-n-play, but there can be some issues with getting it registered. It's been a while since I installed my but I think I had to wait a while after plugging it in because it spent the first 20+ minutes downloading new firmware. A lot of people seem to have problems getting the bridge to register, I think it's because it won't register while doing the firmware download so if you keep power cycling it and trying to register it fails. The key is to let it sit for while. I've had mine for about 2.5 years now. They first released the bridge based product for sale at CostCo and I bought one. Then they pulled the bridge product for a about a year while they worked out some issues. My original bridge and last 5-n-1 sensor have been good. Given the cost, I don't expect the same performance/quality as a $600 Davis weather station. I do consider it a pretty good value. I do wish they'd make the bridge a bit more hobbyist friendly, but I can work around that. The support on the product has been beyond what I would expect for something at that price point. They seem to be willing to send out replacements when there is a problem. There's quite a few examples of that in their support forum (see link below). I think a pogoplug would probably work. The key is that you need two network interfaces so you can sniff the packets being sent by the bridge. I've been working on the software to make it more modular and less specific to my environment. You should also look at the software George created (see below). There's also a commercial product called MetroBridge (I think) that does basically the same. The two places that have information on decoding data from the bridge are: http://moderntoil.com/?p=794&cpage=1#comment-4918 https://support.acurite.com/acurite?topic-list[settings][type]=recent George, http://nincehelser.com/ipwx, is really the one person responsible for most of the information on decoding the data from the c

Great! I had to restart everything around midnight after a power glitch from the lightning so I think the daily total never reset. The .73 is likely what we got since about 10pm yesterday. I'm still getting refused connections (43 since midnight), but none since about 5:30 this morning. I don't think this really effects anything since they're somewhat random and I don't see multiple refusals in a row. I don't think I'm sending (or maybe not properly tracking) monthly & yearly rainfall. I'll look into that. I am sending hourly and daily rainfall totals and those seem to be working. Weatherbug doesn't seem to accept rainfall at any smaller granularities. I don't know that my setup is something worth duplicating. When Acurite came out with a sensor package and internet bridge it seemed like a great solution. Works well if you want to use their cloud service, not so well if you want the data local. I do have the setup somewhat documented at http://www.bobshome.net/weather/

Yes, El Dorado Hills. Before getting my station and getting it to report to weatherbug, I would bounce between Placerville airport and the CTRSH station. Mostly using Placerville. But the temperature difference between Placerville and here would vary between 3 to 10 degrees. Not real useful when used to control when heat or air should be on. You should be able to enter the "p17648" for the station ID and it will pick it up. You can also look at it on-line at http://weather.weatherbug.com/CA/El%20D ... tat=p17648 I haven't been tracking the rain stats, but I'm sending the same values I send to weather underground and my rainfall data is matching another wunderground station just down the street. While looking at it today, I noticed that that weatherbug wants monthly and yearly rain totals so I just added that to the data I'm sending them. It hasn't started raining yet, but it's supposed to tonight. Hopefully the updates to the cloud will make things work a bit better. I'm sending updates once per minute and have seen a lot of errors where weatherbug refuses the connection. Nothing consistent, just burst of refused connections 5 to 10 times in an hour and then it's fine for hours.

Mike, I just looked at this thread for the first time. It sounds like you might be close to my location. I'm running a backyard station now that may provide better data for you depending on the distance between us. I was having a lot of problems with other stations too mostly related to temperature because all the surrounding stations were at quite different altitudes. My station id is p17648 It's at about 1300ft in EDH. I've had some issues with rain data but I think I have most of those worked out. The station just came back up on the weatherbug cloud so I should know soon as rain is on the way. And if the station is useful to you, at least you have someone to complain to if it is having problems