lilyoyo1

With many of the better looking and performing fans coming with remotes, what I started doing was hardwiring them to a relay switch. Since our new fans have 6 speeds, we were able to get a better experience with setting them and never changing the speed. By connecting it to a switch, we get control over the fan via insteon while still preserving the ability to change speeds as we need to

Many people on here won't download things due to virus concerns so you may want to screen shot and attach your pictures for everyone to see. What are the zwave devices that you're using? How close are they to the isy? Do you have repeaters? The more detailed your response the better we can help you. Do you have any programs with the devices in them?

No. While there are some nodeservers in PGC, most are run locally. It all depends what a service requires and what a developer wants to develop for.

It's a local nodeserver so you'll either need to run polyglot on a RPI or purchase polisy for that

Ok. You made me wonder due to mentioning zwave. Just wanted to make sure. Open up the event viewer and set it to level 3. Look at what happens when you try to add your insteon device

Do you have a plm installed with your isy? Are you currently using zwave?

Clear your java cache

Did you click the set button or press and hold until it chirped

Since you're coming from the 99 it'll be more involved. The new unit should be on the 5.0 firmware. I don't know if migration from the 3.0 series firmware would be different than from 4.0. To be safe, I'd downgrade the software to 4.8 and then use your backup file to to restore to the new isy. You can then upgrade to the 4.8 again Once done, you can decide whether or not you want to go to 5.0

Did you clear your java cache

I'm not sure why you can't find it as it's in the middle of the admin console. I suspect that your firmware and UI don't match. In the middle of the screen you can choose from preselects or from the right side you can choose to set your own. This is in the latest 5.16

I'm not a programmer so I can't speak on the programming aspect of things. I do know historically UDI hasn't been one to remove features unless bogs the system down or makes it unstable. Who knows, once the isy994 is EOL and they come out with 6.0 (along with new programming language it's something that could potentially come back. If any programmers know how to program it in without destabilizing things, I'm sure UDI would love to hear from them. If you're not far into your programming and don't need zwave (if you have the zwave version), you can remove the zwave board and downgrade to 4.8

I get that. There's more to 5.0 than what I said. I was just speaking on the major parts of it which effects that particular feature. All in all, the newer adopted features such as what you're doing greatly overshadows what has been loss when viewed in totality. When you do start mixing things that required network resources such as Sonos, hue, and AV equipment, you'll see how much more time you save than you would've doing the the old way

It has been on here and Michel has given the technical reasons as to why (but when someone wants something then the reasons doesn't matter). While I get your example, it's far from being the same in that they didn't remove device capabilities. The 4.0 insteon only setup is akin to carrying around a palm pda, pocket camera, mp3 player, gps system and phone. We gave up battery life, privacy, and a host of other things to package all of those technologies into 1 package. This is what 5.0 is. 5.0 is their future and bringing multiple technologies under 1 roof. In doing so, some features were lost in the process in order to achieve that. Looking at UDI's history, I can promise that decision probably hurt when it was made. However, to keep people interested in their controller and to keep up with the trends, it had to be made. Due to various reasons, that feature never mattered to me. However, I would glad give that up to do what I'm doing now. In some scenes, I'm using up to 8 different technologies. Things I wouldn't have been able to do with the 4.0 branch without doing 10x the work and twice the money (and that's if I was successful).

There is in a way. Its to stay on the 4.0 branch. Im not trying to be smart but the whole purpose of 5.0 is to integrate different things together along with nodeservers and such. If none of that interests a person then there is no need to be on it.

It's all about perspective. That 1 feature worked because there was a single common element... insteon. Now you can add zwave, hue, ecobee, harmony, lifx, and more to a scene....all of which requires their own specific coding in order to work properly. What it boils down to is whether you prefer to use 1 single protocol which is insteon or a multitude of disparate devices with your system.

That's not part of 5.0 due to being able to use different devices into a scene. The best method is to add your responders to the scene, configure them and then add the controllers

I have an easy way..... Turn off the lights. Lol

I have a couple of their motion sensors and not once have I had an issue with them timing out or re-triggering. Granted I use programs vs direct linking which may have something to do with things. From my personal experience with them, they work well for being a motion sensor but not for anything else.

Insteon was always aware that he worked for udi. When insteon asked him to come back, his being able to continue to work on his own projects and udi was part of his terms and in his contract. With that said, he's no longer with insteon at this time. The plm fiasco had nothing to do with that person. As I said before, short sighted decision making. It's this decision making that made them jump in bed with apple in the first place and almost bought the company down. That single decision is the main reason why JD ended up needing to sell the company.

Yes

I highly doubt this is a conspiracy of insteon to see to UDI's demise. In fact it hurts them more since UDI is a large part of their consumer base. Having those users unhappy doesn't serve them well in any capacity. All that would do is make them use devices from a competitor. Being that one would need a strong mesh, that means additional devices from zwave instead of insteon. Their issue is short-sightedness. They make insteon only for themselves vs involving other companies in the process to ensure products work in full with other controllers.

Setting the iolinc to Momentary C will allow this

My goodnight programs simply issues close and lock commands. I don't worry about the checking status of something. That way if the status is wrong the action still happens

I only use the Isy so ai can't speak on integrating the 2 together for your program to work. However, I would recommend using a kpl and fanlinc together (I use them myself) but they are linked and controlled directly by the scene itself. You didn't say what specific problems you were having with syncing. One thing I would check would be to ensure the isy itself is receiving the information from HA and is updating itself with the proper status. If the statuses are being updated properly then the programming portion would be easy. The main thing that jumps out at me is that there is nothing to trigger your "or else" statement. If status of fanlinc is low And status of fanlinc low is not off Then set kpl on Or else turn kpl off