paulbates

I've had a theory that you've forgotten more about the the ISY than the rest of us know...

The original post was made in the Echo / Alexa forum

Variables can be initialized to a value that is saved in NVRAM and survives reboot. This can be done manually in admin console,. but also with programs. To add to Benoit's program: If sensor=detected then variable=1 variable init to 1 else variable=0 variable init to 0 That assumes a change doesn't take place during reboot. For me, reboots are as short as they are rare... either I updated firmware... or a power outage Paul

Drew Yeh that’s a new one for me, but you’ve tried everything I know. Hopefully the replace works for you Pauk Sent from my iPhone using Tapatalk

For the program question If door sensor open is on then wait xx minutes (hours, seconds, whatever you want for the open period) send notification If the door closes within the time you specified, the program will cancel and no message. If the wait finishes, you'll get a message Paul

I've had great luck using insteon keypads and button scenes in rooms as 3 - 4 ways for turning on laps, fixtures and low voltage fixtures purely as virtual circuits to save extensive wiring changes to meet the design. The lamps are set to come on at a certain outside dusk and off at a certain time, and there is a "good night" button on the way upstairs that will turn everything off. I keep backlight on as darkness navigation aid. Paul

No, because it requires a Post and the browser issues a Get. You could use a chrome extension like postman to simulate it. Paul Sent from my iPhone using Tapatalk

Traffic on http:// is not encrypted and travels open across the internet. I believe this applies to authentication as well, meaning your id and password travel the internet un-encrypted when you remotely access your ISY. If you have firewall rules forwarding the internet via http:// port 80 to your lan, those rules should be removed and another way found (https://) to accomplish the same function. Paul

Dyndns requires a client on your network to publish your local internet IP address to dyndns. That client informs the the dyndns service so that your unique DNS name resolves to your house. Most routers have the client in them today and that's where it gets setup.. but it doesn't have to be. It has to be somewhere though. What services are you exposing to the internet? Having http exposed to the internet is not a good security practice. Its more likely that you are exposing https to the internet for things like mobilinc, etc. If that is the case, you're getting the message because your local network never responds to http... which is actually a good thing from a security perspective. Try changing it to https on the dndns health check app and give it a day or so and see if it resolves. I'm not sure if mobilinc (if that's what you're using) uses the default path or something else. Let's start with changing it to https Paul

When you get a host name for your network from dyndns, it redirects the URL back to your home network. The purpose of the message is for dyndns, the service, to validate that there is a clear path to the target, your home network. If you are getting errors, its not able to resolve that it can contact the configured devices in your home... That leaves 2 possibilities for the message: Your home network, or the path to it, is unreliable... (I don't accept this one in 2018, but its possible) Firewall rules, dyndns configuration or something else is preventing dyndns service from seeing the dyndns client on your network Let's assume its 2 for the moment. How is the dyndns client setup in your house? Does your router provide a dyndns client, or are you running it on a pc or something? How did you configure the service? Can you post a pic of the config (masking the sensitive parts?) Paul

Ok This is a known problem that occurs occasionally. Sometimes its the load, and you've eliminated that. It unfortunately gets more complicated from here and involves filtering of select non-automated switching powersupply devices in your house .. example, UPSs can cause this. Take a look at this thread. As you scroll down to May 7th in the exchange, the problem gets solved and that resolution may help you. Paul

I have a couple of these around the house for big groups of lights. Yes, to your comment, create a new scene with all of the devices to be controlled as responders Add all keypads and switches that should activate the scene as controllers.. its a check box when adding devices to the scene If you added them already as responders only (non-controllers), remove them and re-add them Controllers names will be colored red in the list of devices in the scene Its a subtle thing with the ISY; making it a controller also makes it a responder at the same time.. so if there are multiple keypad keys to control the scene, they will also respond to other controllers Note that Smartlabs has been removing the All-on feature of insteon devices from their switches for a few years due to operational problems with it. You can get around this by creating your own scene as outlined above. That works fine To your last comment you can create specialty scenes (the lights and fans comments) that are close but different from other scenes for special purposes. I have some of these that I only turn on and off from ISY programs. There's more to it when it comes to dimming. This gives some more details Paul

Hi and welcome to the UDI forums! What is the load that the microdimmer is controlling? LED Bulbs? Can you temporarily replace those with a different type/brand of bulb and test again? What happens? Paul

If you literally use the "Delete Modem" feature, it removes all of the links that the ISY programmed between devices. You don't want to do this. However, the ISY and PLM is the fastest way I know how to set up links between devices and not have to use the labor intensive manual "linking mode" between insteon devices. You are right that insteon devices link device to device, no PLM or controller are needed after set up. The ISY and PLM cand fail after initial link (scene) programming, and your light switches would still work. However, using "delete modem" should never be used unless UDI support suggests it. Paul

Hey Andrew 2 things: Did you try a factory reset and then right click on the device in the admin console and pick "restore device"? I've had a couple of my insteon devices get "confused" after a few years of use when their at the edge of the electrical system and/or controlling noisy loads. A factory reset may fix it. Here is the replace procedure. Paul

This is very unusual. The place to start would be. Can you be specific about which local API you're talking about? , (eg assuming Rest). As secondary test, can you pull up the ISY's internal web page on a computer http://<your locally administered address> ? How does this do? I believe it uses the rest interface when it gets status, variables, programs... turns things on and off Provide a view of the event log and error right before the problem happens through right after Paul

Ok got it. Good luck, would love to find out what's going on here Paul

Ok. This program is not enabled, which means its not running on its own, regardless of the status of the sensor. Can you share the program(s) that calls James_Front_Entry_Text? In the ideal world, you should have this program enabled, and no other ISY program calling it. If you only want alerts at certain times, you can add another program statement that sets a time window Paul

Can you share the program that sends the alert? Paul

See that's another difference: You organise your folders, and Scott organizes them

Yes fair enough. I listed IFTTT because i did set up geofencing on it, but now thinking about it I have since migrated off of it for ISY Portal and don't have any active IFTTT any longer. Using it would take choosing where functions should be implemented For network resources, I've drawn the line on only getting iot devices that support a local API, so I'll not have issues there. I plan to turn the router over with ISy and IoT as the local IP addresses matter, but no cloud dependencies. Paul

One thing you can do is have a "house" email account for as much technology as possible. My Venstars, alarm system, rainmachine, IFTTT and pushover all use the same gmail account that is used strictly for administration. I need to change my ISY Portal account to the same one. The account password can be changed in the presence of the new owner and the administrative handover is done. If things like mobilinc and Nest are authenticated with an email account, that could be done as well. Alexa would be the only thing that this approach won't work for. Paul

The other advantage of @PhanTomiZ's second option is that you won't be using power 100% of the time for the step down transformer. Probably not a ton of power, but a tad greener. Another way to implement his option 2, instead of the on/off module and having things laying around plugged into each, you could replace a receptacle with an on/off outletlinc and plug the transformer into the wall. It doesn't have the flexibility he mentioned but it might make it a cleaner install. Paul

Dashboard had been around for a very long time. Its always been a separate download in the download instructions for new FW versions. I think the origins of it was to have an operational / runtime environment separate from the build and configure role of the Admin Console. But things like the JSON based Home Automation Dashboard (HAD), Mobile Apps and third part public domain Home Control packages took over big chunks of the control space. The dashboard does have some specific jobs that the Admin Console can't do, like setting up user provided SSL certs, and configuring the smartmeter option - ADR / AMI, if you have the specific ISY accessory board for that. Not sure about the FW update message. My guess is in the dashboard, it is just a message, and the AC is the place to go to do the upgrade. Guessing again, but I'm not sure what the future of the dashboard will be when the admin console migrates off of java. The specific configuration roles listed above might be wrapped into a single web app, and let mobile apps, etc provide a "remote control" capability. Paul

My comment was more around core operation of the standalone 2441TH working with the HVAC system, even if insteon was not linked. I could not get the 2441s to operate correctly as a thermostat, despite being shipped multiple 2441TH replacements. I had a 22 year history with other thermostats on the same HVAC systems: Beginning with the original Honeywell contractor thermostats (non automated) and 7 years with RCS TX15 Thermostats (x10). The 2441THs locked up, changed modes on their own or went into continuous heat calls, where we'd wake up in the middle of the night with the house over 90 degrees. We debugged it over several weeks and fortunately it was not winter and I could turn them off. SH eventually threw up their hands and gave me refunds for them and I reinstalled the RCS TX15s while shopping for something else. I ended up with non Venstar non insteon thermostats that I'm really happy with operationally and features/function. I know this doesn't happen to most 2441 users and glad they work for most. However there's a very long thread around here about this specific problem and how others attempted to address it by soldering on the units or putting filters on the 24VAC lines; its a design problem. Its worth looking through the reviews at SH. To the OPs point, the Heat Pump version appears to have been withdrawn, there are only 3 reviews and the newest one is 3 years ago. Paul