apostolakisl

Not a bad thought.

By trim, you mean the led bank? I always thought it was a little odd that the on/off switch had all the intermediate led positions. But I also can see why you would want it to look the same as a dimmer switch. What to do?

I have a feeling you are right. My research would indicate the way these work is 1) You toggle on power 2) The transformer/ballast powers up and outputs 10v through a fixed resistor limiting current to a few milliamps. 3) A variable resistor in the dimmer (I suppose an old fashioned rheostat) sinks that current to ground resulting in a voltage drop proportional to the resistance applied. With the resistor at infinity, the voltage stays 10 and the lights are dimmed to the max. With the resistor at 0 ohms and drops the voltage to 0 and the lights ramp up to full.

If Insteon just didn't discontinue the purpose made version. I'm sure the demand was very low, but still, they already did the r and d on it.

No. Like I said, it is a $50k system. I'm not going to do that.

This is a very fancy high end led set of fixtures that lights up a dome in my church. 0-10v is used in fluorescent lights, but also leds and theatrical lighting. The lights are staying . . . they cost like $50k. EDIT: This article pretty much tells you what I'm dealing with. https://www.acuitybrands.com/products/detail/257121/fresco/fresco-dxt/-/media/products/Fresco/257121/document/0-10VDC-Best-Practice_pdf.pdf

I am trying to use Insteon on an led fixture that uses a 0-10v controller. Any ideas on how to get this to work with Insteon? At this point I'm thinking that my only option would be to use an Insteon on/off switch on the main power supply and continue to use the 0-10v dimmer for control of brightness. EDIT: It seems the Insteon has discontinued the product I need. Not sure what sort of reasonable workaround exists.

I do believe that it shows that exact error twice often. I just logged in right now 5 times and I got an error every time. Once I got a single instance of the DHCP error, and 4 times I get "request failed" (the request failed error is one I haven't seen before just now). Also, it sometimes gets stuck on "starting subscription" at which point I just have to close it down and start over. All 5 logins I just did seem to work fine once I closed out the error. I don't believe I ever log in and don't get an error on this ISY (I have two). The other ISY I typically login via the local LAN, so I don't have as much experience as to what the portal does for it.

Did you upgrade firmware? Did you try admin/admin?

Thanks for that. Didn't know about notify me.

Generally speaking, an alarm system is required by local code to be monitored by a central station. If you don't have a siren, perhaps not, since no one will ever know if it goes off. But there are plenty of times when I am not going to get a text or an email immediately. Or perhaps I'm being held at gunpoint and the intruder isn't keen on me calling the police. I think that central station is worth it for the $120/year.

I've used google and amazon with ISY just for voice control. Like mwester I am not aware of anything else it can do. I also am not a huge fan of everything going to the cloud. Unfortunately, no one seems to be making any speech recognition product that keeps it all local. My voice control so far includes lights and my whole house audio system. Unfortunately, my whole house system does not have any integration features, so I have had to use a global cache and teach it all the IR commands and then use ISY network resources to trigger those.

Every time I login it says "error - no network connection [[DHCP] state=RENEW]" Despite the error message, it all seems to work.

No doubt, hard wiring into a real UL listed security panel is the gold standard. If linked to ISY, you can both have a proper security panel call to central station as well as an ISY initiated action (ie email, text). That is what I have done. I get notifications by text as well as getting a call from central station.

With the io linc, you can use the GRI sensors. GRI is a security system "industry standard" Very well respected. Just make sure you have good com with your io linc since they are not dual band. Maybe consider putting a lamplinc on the same outlet with it if there is any question about it. The iolinc only has a single input, so you will not be able to independently monitor more than one sensor at a time (with only 1 iolinc). Though you can have multiple sensors that run in parralel or series (depending on if you get the NO or NC leak detector). If you want power outage protection, you'll need to put it on a ups and then you will have to have a dual band device since the ups will block the power line com.

The absolutely easiest solution is this https://www.smarthome.com/insteon-2852-222-water-leak-sensor.html Mount this in the well at a level above which you would like to be notified. No wires, no power, no nothing. Just link it to your isy and write some programs. You can even get 2 or 3 and mount them at different locations as redundancy. I don't have any ground water issues (my well is 800 feet deep!) and have no sump, but to mitigate any pipe/appliance leakage I put gri2600 http://www.grisk.com/images/product_pdfs/liquid_detection/2600_12volt_dc_water_sensor.pdf water monitoring all over my house, about 20 sensors maybe more. They are all wired directly into my Elk. GRI also makes a submersible water presence sensor. http://www.grisk.com/images/product_pdfs/liquid_detection/2808_absence_water_sensor.pdf This would be ideal to put just below the pump shut off level. If that sensor goes dry, it would either indicate drought, or a pump that has failed to shut off. These sensors will require that you get an io linc or wire into a security panel or similar. The GRI unit saved me huge already. I had a slow leak behind the dishwasher that was running water under the hardwood floor. The leak detector sensed it even though there was no water evidence at all. I cursed the water sensor as having failed and reluctantly pulled the dishwasher out. And then, I stopped cursing it and started cursing the plumber.

There are a bunch of off-the-shelf float switches out there. Just do a nice secure installation and you should be good. From there, you can hook the float switch to an i/o linc and program ISY to do whatever you want. You can also wire it up to a siren directly so if for whatever reason the i/o linc/ISY/email thing failed, you would still have that whining siren. Other fun options include using an ultrasonic range finder and wiring that up to a cai webcontrol. There is a node server for cai webcontrol posted by ioguy which will allow easy isy integration. This will tell you exactly where the water level is. Basically, it outputs a voltage based on the distance between the device and the reflection surface (the water). ISY would show the voltage and then you would need to scale that number to inches or whatever. And another thing is to use an synchrolinc on your sump pumps electric plug. From this you can be notified if there is too much or too little run time. EDIT: It seems that synchrolincs are no longer a thing. Anybody know anything about that? Is there going to be a new device replacing it or is this just never to be a thing again?

Seems like a flow chart diagram is warranted here. And in the wiki. I am in a similar situation with two ISY's. I did manage to get it all straight. While I'm only using Alexa at one of them, I'm using Agave at both. I had to have two user profiles and set one ISY as primary for one and the other profile as primary for the other ISY. I believe the Agave relationship with the portal is the same as the Alexa with regards to that. EDIT: Check that, I actually created two separate portal accounts. Perhaps I didn't need to do that.

Two problems with this. 1) At least on my phone, the app goes to sleep. It does not update the geo fence unless you open the app, except every once in a while seemingly at random hours after I had already entered the geofence. This is despite me giving it every permission I could find that might undo limits on its background wakes/batter usage. 2) There is a good reason that Android might want to shut it down. GPS geo-fencing is battery intensive. Tasker plus wifi status is nearly a zero battery kill. It is also extremely quick and accurate. If you want to keep your GPS drainage down, you need to limit it to say every 5 or 10 minutes (if it works at all, which in my case it does not). Even at that, the phone will continue check every x minutes 100% of the time. Going on a vacatoin? You'll get a gps check every x minutes even if you are 1000 miles away. Using Tasker only requires that you keep your wifi on. Which for most people is standard. Of course it also depends that at all geo-fenced locations, you have wifi.

Did you setup the node in ISY for occupancy? I would use this over a variable. It does not require authentication aside from what is in the post itself and it is a node, much nicer than a variable (intuitive and easily accessible for programs and status checks). Did you copy and paste into Tasker as a "post" the https://my.isy.io/api/occupancy2/ . . . /in(or out) that the portal lists as the trigger for changing your occupancy node status? I also put a "wait" command into Tasker on the exit from wifi of 5 seconds to allow my phone enough time to establish its data connection upon dropping the wifi. It is worth noting that my wifi connection is my geo-fence indicator. This has been working flawlessly for me.

I actually didn't say that any behavior was "correct" or "incorrect" I only said what the behaviors were. I'm also not sure why you are making a distinction between the "load balancer" and "the portal", the whole thing is "the portal", they are inseparable. Furthermore, there is nothing incorrect about saying the portal is not truncating the string variable into a numeric variable. This is a very important observation because of the fact that a REST to an ISY DOES. I did say that including units is more than just useless. It would be a crippling blow to the usefulness of the weather module if not for this "error" of the ISY REST handling. I also said that in its current form, you have to do a crazy workaround to use weather module data in anything more than the most basic and simple comparison (ie is temp greater than 80) Again, units are completely useless. You can add the units if you want to a notification email or text using isy's standard notifications format, or at the target device in a more generic sense. I have been using weather module data for a very long time via REST only and just always assumed it was only a numeric value, because 1) it made sense and 2) that is how it worked in that context. EDIT: I would also like to point out that UD is pushing their luck with the 128 character limit on path. The encryption string is huge and pushes very close to that limit. If memory serves, I was at 115 characters with the path using variable substitution.

I tried two REST commands that set a variable, one ISY to ISY, one ISY to portal to ISY. First off, I just sent a single integer value to confirm all my settings, no problem on either setup. Second, I tried appending that same REST command with a space and letter. ISY to ISY it truncated off the letter and worked fine, ISY to portal to ISY gave error. In summary, it appears the portal does process the REST command and does not truncate and therefore fails. Seems like an unnecessary thing for the portal to do (process the REST command rather than just forward it on through). But my workaround does fix it (the workaround being to first network resource the weather module value back to yourself so that it becomes a normal variable) TAKE HOME POINT: The knowledge that you can network resource a weather module variable back to yourself and clear out the useless units and open it up for using as a comparative value or do math on it, or send it to another isy via the portal is worth something. To the best of my knowledge, looping a weather module value via a network resource is the only way to use a weather module value as something to compare to anything but a fixed value. For example, if inside temp (from a thermostat) is higher than outside temp (from weather module).

No, I tested this and posted it a couple posts ago. I just did simple REST commands ISY to ISY and added %20 followed by random letters to an otherwise functioning REST command. ISY returned error every time. ISY to ISY using the weather module variable substitution does not.

Except F and % sign apparently are part of ${mod.weather.temp.current} and ${mod.weather.humidity} YET, they still work direct ISY to ISY REST to a var. The exact same thing through the portal does not work. So I don't know what code is in there that tells the receiving ISY to ignore the string and just use the integer. And why this is lost with the portal? Whatever code it is, it is not %20. %20 seemed like a good candidate since in the email that seems to be the only thing separating the integer from the F or % sign.

A percent sign does show up in the email for humidity. None-the-less, it works. I tried test REST commands to my isy putting a %20 after a number (url for "space") thinking maybe isy truncates at a space, but it does not, it gives an error. For example, http://192.168.1.9/rest/vars/set/2/26/8%20 So there must be some other character there that tells it to truncate . . . cause it works when you use variable subsitution for temp and humidity. I would expect that the portal is not "understanding" the REST command, but rather just truncating all credentialing since it has already established a session with the target isy. There really would be no need to understand or interpret the command at the portal level.