apostolakisl

Upon doing my first IFTTT to ISY command via portal, I realized that this is just a POST command and has nothing special relating to IFTTT. I have since used several other methods of sending a portal generated POST command, including sending a POST from ISY network module to another ISY. It all works. In short, the IFTTT label in the portal could have its title broadened such that it is clear that it simply generates a POST that is able to be implemented by anything that can do POST. It is a bit quicker and easier to use the portal to create the POST command as compared to using REST and looking up all the various REST commands and values. It is basically a "gui" way to make a REST. REST does have more features, but if what you are doing doesn't need them, it is quicker and easier to generate a POST using the IFTTT section of portal.

If the two panels are both behind the same electric meter, then there will not be any lack of a "covered phase". The Insteon comm will back and forth through all the panels so if both phases have comm behind one panel, then they will behind the other panel as well. The 500 foot distance (times two) very well could be an issue. You might need to add an Insteon device in the middle to help repeat the signal. Also, using dual band devices that are within rf range would help. For example, if your sauana and stuff is located directly next to your house, then an rf device in the house only needs to make it to the rf device in the sauna, it doesn't have to go 500 feet to the main panel and back out 500 more feet to the sauna. In my experience, I have run power line comm devices on wire runs of a few hundred feet without issue, but never 1000 feet.

I agree about the wrench. I thought it was an "x" as well. Even after I realized it wasn't an "x", I still didn't recognize it as a wrench.

I have 9 of the Insteon thermostats for heatpumps (which they discontinued) working AC units at my church. Pros: 1) They were VERY cheap, I think I ended paying less than $50/ea 2) They integrate with ISY simply, quickly, and natively 3) It is easy to control them from ISY programs, mobile linc, and Agave 4) With version 5 of ISY firmware and the portal, they are easy to control with Alexa and Google Cons: (note, some cons may also be present with other thermostats, I don't know) 1) They can get messed up with power fluctuations after which they need to be manually reset. This would obviously be a very big problem if you were out of town in winter and it happened. 2) The "cool on/off" and "heat on/off" are Insteon control commands sent by thermostat. Meaning that if the comm misses, you can't query it. ISY (or any other scene responders) simply don't react to this call for heat/cool or shutdown of heat/cool message and never will until the next heat/cool cycle. 3) They don't activate heat strips when weather is too cold for heat pump to work well. You can manually turn them on however (not from ISY, only from the thermostat). 4) The native programming on the thermostat is quite good, but it can only be done from the thermostat. This is no issue for me since I use ISY to do all of that, but still it is a PITA using the little buttons on the thermostat. 5) The stage 2 cool is fixed at the temp being 5 degrees from setpoint. This isn't the greatest. It would be better if it had logic such as "if temp hasn't satisfied within x minutes, activate stage 2". 6) The LCD screen isn't the best. You have to look at it from the right angle to see it.

I picked up those two venstar thermostats on ebay. They are used, but that is all that is out there right now for Insteon heat pump thermostats. I'll probably replace one of the Insteon ones with the Venstar one and see how it works. If I like, I'll put the second one into service as well.

Thanks for the info. With that model number, I googled it and discovered that they have a couple Insteon models. The base model on this one is T1800 which is not Insteon compatible except for a sub-model of it (2491T7ER) which is a native Insteon model. Not sure why they didn't change the T1800 name, it is confusing. Interestingly, today, the dead thermostat started talking to ISY again. It is still not functional however. I can change the settings on it, but the screen is black and it does not seem to turn the system on nor report temp/humidity. But it does respond to query and it does allow me to change the set points and mode. EDIT: The thermostat has now completely come back to life.

I installed Insteon heat pump thermostats at my church a while back (9 of them). Well, on Monday, an oversized truck driving down the main highway next to the church hooked onto an overhead powerline and ripped down a whole block worth of power lines. A huge mess, they are still out there doing repairs as of last night. The power went crazy causing half of the thermostats to need to be reset and one of them appears to be just dead. (also screwed up other electronic devices). Insteon no longer sells the heat pump version. I found this on ebay https://www.ebay.com/itm/292710000156?ViewItem=&item=292710000156 Can anyone confirm that this will work? I'm using ISY to run all the schedules, not the thermostat. I'm hoping to just use the "replace with" function. It was my impression that Venstar required an adapter, but the person selling this says it does not.

Back to the OP. It appears that using scenes with the remotelinc will not work based on that fact that you can not send a status update to a remotelinc. So you will need to rely on programs. Unfortunately, programs have a lag as compared to the near instant response of a scene, but unless you want to switch to using kpl's, that will be your only option. Just fyi, they make desktop enclosures for kpl switches with a wire that you plug in to an outlet.

That may be true. It is a battery powered device so it goes to sleep and thus can't respond. It may be an "outbound" only device.

I'd be shocked if you can't. Just log into your admin console, right click the the remotelinc button in question and add it to your scene as a responder (ie add button b to scene controlled by button a). Scroll down to the scene, and click on the controlling device for the scene (ie button a which will be shown in red). Then you'll see a list of devices on the right with their "on level" and ramp rate for the scene when controlled by (in this case) button a. Click on the remotelinc button b in the right hand top window, and you should see options for both on and off in the right bottom window. EDIT: And if you should also set the "on level" to "off" for the scene when controlled by ISY by clicking on the name of the scene itself in the left menu and then doing the same thing to the right hand windows as above. EDIT 2: Just to summarize, what you are making here is referred to as "radio buttons" Like in the old fashioned car radio. Pressing any of the 5 or so preset buttons would cause whatever other button was already depressed to pop out. Only one button can ever be on at any given time.

I can't say for certain either, but the behavior he describes would indicate they do. Since he says it turned the scene off when he tried to "go back" to that scene. If it didn't know that its last press was to go on, then how would it know that the next press is to go "off". EDIT: Also, per his report, it has the ability to be set to "on only" or "on/off". It would have to remember its status to be able to function in an "on/off" fashion using the same button.

That is because you didn't set the other buttons as responders with "off" as the "on-level". The last line in each of those two scenes would fix that problem. While I don't have a mini-remote linc, I believe they function the same as a kpl just without backlights (since that would kill the battery). EDIT: Also, please note that this example is for 2 buttons controlling 2 scenes. If you had 3 scenes, then there would be 2 lines at the end shutting off the other 2 buttons, and so on if you had 4 scenes, or 5 or whatever. Again, the only caveat is if you manually change a device in the scene. For example, push button a, scene a turns on. The button a will currently have an "on" status. Now say you manually do something to one or more of the lights in the scene. That button a will still be registered as "on" even though the scene is no longer technically on. If you push button a at this point, the entire set of lights will shut off. It would be more appropriate at that point for a push of button a to turn the scene back "on".

I think you are making this too complicated. You should not need any programs. Don't use the toggle on only mode. Just put the buttons into regular on/off mode. You can switch between scenes at will and it will not make the lights turn off and then back on. For example, say you have 4 lights and 2 scenes. Scene 1 KPL button a is controller of scene, all else below are responders: light a on level 80% light b on level 50% light c on level 0% light d on level 10% kpl button b on level 0ff (realize that the kpl button here is a responder, when it responds and is shut off, it does NOT execute its "duties" as a controller of scene 2). Scene 2 KPL button b is controller, all else below are responders: light a on level 20% light b on level 10% light c on level 100% light d on level 0% kpl button a on level 0ff (and vice-versa of what I said for scene 1) Push KPL button a and will go directly to those settings. Push KPL button b and it will go directly to those settings (it won't go off first). Push KPL button a when KPL button a is already on, it will shut all 4 devices off and all both kpl buttons off. The only thing you might want a program for is if one of those 4 lights changes status independent of the scene (ie someone pushes the button directly). In that case, you might want the kpl buttons to turn off (not have the backlight on). For example, the 4 lights in scene 1 have specific levels defined. When you turn on scene 1, the kpl will light up. Now if someone manually turns one of the lights off, you might want the kpl button to go dark. A program that checks for any change in the status of those 4 lights can be used to turn it off. This is a little complex and you may not care to do it, so I'll skip it here.

Did you mean to say "if status is on" for one of those? Having those two identical lines "anded" won't serve any purpose. But using "status on" won't serve any purpose either for a kpl button that is set to send "on" only. Since it will always be on anyway the line would be useless (always true), unless perhaps you have some other scene or program that shuts it off. Is this KPL button's only task to shut the scene off? If it is also used to turn the scene on, then that won't work.

I googled this, and it looks to me like the 0-10v signal works the same as for lights. So the device above would work. I base this on what I see here. http://infratech-usa.com/wp-content/uploads/IN023_ControlsBrochure_020718_mh_FNL2_sngl.pdf It states it works with standard dimmers from Crestron and the like. And these dimmers don't generate the 10v, the only "dim" the 10v.

With a little luck, maybe the Insteon switches won't need a dummy load. Not that a little night light is a big deal.

This appears to be what is needed. Though I'm not 100% sure since the specs here are . . . well . . . what specs? But it looks like you take your standard triac (Insteon) dimmer and run the load wire into this device. Then this device controls your 0-10v based on the dimming level of the triac side. https://www.ebay.com/itm/Converter-from-Triac-dimmer-output-to-0-10V-dimmer-signal-or-PWM-VDC-dimmer-/272911268235 EDIT: Found better literature (and price) http://digitallighting.com/animationfolder/specs/manuals/DT-AN10-PWM.pdf EDIT 2: And a better price https://www.idealstar.top/dtan10pwm-vac-triac-dimmer-to-010v-analog-signal-pwm-dimmer-converter-p-10006.html

I suppose you could apply negative 10v to the pos 10v output to get a 0, and anything between 0 and -10 for other values. But if I damaged it, that would be very bad. I'm going to stick with the design which is to bleed down the voltage by sinking some current to ground through a variable resistor . . . or do nothing at all. And yes, the entire series of fixtures is on a single driver with a single controller (dimmer).

The drivers/transformers for the lights are in the attic. The switch is in a normal single gang box.

In the thread I started about this I linked to a pdf file that describes it quite nicely. It works very much like an alarm system zone. The panel produces the voltage for the zone. The alarm panel reports a voltage then on the zone, not because the voltage was sourced from the target, but rather the target either left it alone or reduced it by shunting some or all to ground. The order is as follows. 1) The device itself has a transformer producing 10v dc 2) Next in line is a resistor 3) Next in line is a voltage meter 4) Next in line is a variable resistor (your dimmer switch) that reduces that voltage by running it through a variable resistor bleeding off some or all of the volts to ground. 5) The device dims itself internally based on the measured voltage. The voltage itself pushes out milliamps of current, that current is only a signal, it does not run power the light. EDIT: They don't even do 1 mA. My reading would indicate about .15mA.

I can't speak for sure to this heater you have, but . . . The 0-10v dimming of lighting is not accomplished by generating a 0-10v potential and presenting it to the device. Rather, the device generates the 10v output (current limited to very minimal) and the controller uses variable resistance to drop that voltage. With resistance to 0, voltage drops to 0, at infinity, voltage is 10. In short, you need ISY to control a potentiometer.

It just occurred to me, how does making it a node change any sort of access fee that would be involved for getting the weather data? I don't really know exactly where the weather data comes from or how it is billed. Is there a single one time charge for access that UD incurs with each subscriber?

Did you mean to say Elk also should become a NODE?

I think it makes a lot of sense to have the weather module be a node rather than a module. I suppose you might say the same about the Elk module. Though if in the process of becoming a node it stops become a module, would that not require re-writing any programs associated with it?

When I first started setting up the portal, I didn't fill out one of the fields listed as optional, I think it is the "company" field. It appears that this is the field that then labels the portal account on the ISY admin consoles portal tab. I have gone back to see if I can populate those fields, but I can't find any way to edit any of that. Now that I am adding a number of accounts for different people it has become a problem with the portal defaulting to "none03", "none04", etc. Is it possible to go back and label these accounts? I can't find anywhere to do it. I'd rather not delete and start over.