Goose66

I guess it is a little reassuring to see a guy in an Insteon shirt at a show. But no information in the article or the interview on what may be coming, other than "it will be better ... down the road at some time." And I don't buy for a minute that this guy has traveled all over the World installing Insteon. I mean, does it even work in 50Hz electrical systems?

There are posts in the "Press" section of the Insteon.com website as new as January of 2018, but it appears there has been no new products since the Motion Detector v2, which is over two years old now. Are Insteon products still be developed? Is there an end date for these products that has been announced?

It seems to me this would basically remove the ISY from the equation. I see the point of the Alexa portal to be a voice interface to the ISY with the ISY containing the smarts of the system. This seems to me to be a way for the ISY to act as a device bridge or hub with the Alexa device containing the smarts. If this is the goal, why not buy sensors and switches that work directly with Alexa and remove the ISY from the equation altogether? EDIT: Well, except for these: You can ask Alexa if a door or window is open before arming the home security system A front door contact sensor can activate Alexa to announce that the front door is open

I would love to do my AV mapping through the ISY Portal instead of using whatever 3rd-party skills go with my individual AV devices and remotes. That's what we are going for with the ISY, right - the central controller?

I suspect the greatest danger is the same here as everywhere else on the Internet: people using the same or similar credentials for the UDI portal and forums as for other, more easily compromised sites, like your Domino's Pizza account or your online gaming account. We can talk about UDI implementing 2FA for the portal and newer security suites on the ISY, but I would bet 60% of the users will continue to use a single password for all of their vulnerable web accounts.

So this may be a situation where the hint says, e.g., it is a motion detector, but it has driver values to support both. A front end developer would then display it with the motion detector interface of the front end GUI, but display the temperature driver value as an "extra" value. Later, if the front end developer decide she wants to support that node "natively," and implement a specific GUI for it, she could recognize it by the nodedef id attribute, perhaps. There's no point in making a list that includes every possible combination a developer could come up with. That's how you devolve into the nonsense that Michel was concerned about. @Jimbo But I agree with you - to make the nodes most compatible with a generic front-end interface, like Alexa, you would want motion to be one sensor node and temperature to be another sensor node.

Oh, I thought this was for Alexa based on the topic. So the Unlock by code is for Google Home only? Also, I was asking if there was similar functionality in the API (for Alexa) for "Open" and "Close" as there was for "Lock" and "Unlock."

Is there any way in the API to implement that functionality for door open?

Magnetic contact sensor - you mean like a float switch? I will look for something along those lines, although the water doesn't really pool anywhere where a float switch could be used. I was thinking more of a damp or water contact type sensor.

I have a couple of spare I/O Lincs that I would like to hook up to a water sensor to inform me of roof leaks while we troubleshoot a roofing problem. Unfortunately I leave to go out of town on Sunday for two weeks, so it is something I need to throw together right away. Anybody know of something I can buy at Lowes or Home Depot tomorrow to use as a water sensor that can be quickly interfaced with an I/O Linc? EDIT: I just got the Z-wave module as well, so a Z-wave solution would work, as long as it is available commercially at a Lowes, Home Depot or Best Buy.

No times because the ISY only supports integer state values - no strings or timestamps. So just door state: Open, Closed, Closing, Opening, Stopped, or Unknown. I am hoping that a future version of the ISY firmware will allow timestamps.

Don’t know about Google Home but Alexa generally won‘t let you open doors for security reasons and you can’t “close” devices on ISY because they don’t show as doors in Alexa app (you get a “(devicename) doesn’t support that” error). You can, however, turn on (open) and turn off (close) garage doors. I have a program that specifically closes all the garage doors and that’s all i expose to Alexa.

The 5.0.X firmware branch supports external nodeservers that provide interfaces to devices outside of the Insteon and Zwave devices natively supported by the ISY. Polyglot is a runtime environment developed by community members and installed on an RPi running on your LAN (or could be compiled for other platforms) that allows you to install third-party developed nodeservers (also referred to as "polys") to support various types of devices. There is a Polyglot nodeserver (developed by me) that supports MyQ compatible door openers. More information on Polyglot: https://forum.universal-devices.com/forum/111-polyglot/ More information on the MyQ Nodeserver:

That's right - it had a patch for the weather data or something like that.

Firmware 4.7?!?

In my setup, the MyQ nodeserver polls for status every 20 seconds when there is door activity (a door opening or closing), or on initial startup, and then drops back to a polling interval of every minute when the doors have been idle for 5 minutes or longer. However, I have a program that is triggered by an On command from the motion sensor in the garage and, when motion is detected, forces a query of the node for the corresponding garage bay door from the MyQ nodeserver. That way, if the motion is due to, e.g., the door opening, it will perform a query and return the "opening" status for the door right away instead of waiting for the poll. If someone walks into the garage is and is walking around, it will query the door status every time an On command is sent from the motion sensor (about every 10 seconds).

+1 for MyQ Polyglot Nodeserver. The status of the door is through polling, which can be like every 3 to 5 minutes, so the status is not real time. But the opening and closing are real time, and you can use a motion detector in your garage (or your window/door contact sensor) to force the nodeserver to poll for door status from the MyQ service via a program.

Does your new router have a firewall? What DNS server is setup in the new router (it will be delivered to the ISY in the DHCP network configuration)? Check your system configuration page to ensure "Automatic (DHCP)" is selected and also your "About" dialog box to ensure that your administrative console version matches your firmware version. Also look at the TCP/IP configuration on your computer to see if maybe the DNS server is overridden for it. This would also point to DNS in your new router not being setup properly.

As to static IP addresses, I tend to prefer DHCP with specific IP address assignments in the router/DHCP server. Most modern routers support DHCP IP address assignment. This gives you the same advantages as fixed IP without the configuration having to be maintained at each device. In addition, the router can show the status of the device in its administrative console, where there may not be status available for devices with static IP addresses if there has been no outside routed traffic. An additional advantage is that most modern routers also provide a DNS server, which acts mostly as a DNS forwarder but will cache names and keep device names and their corresponding DHCP provided IP addresses from the LAN side in the DNS cache, whereas devices with static IP addresses generally will not report their device names to the DNS server.

Those are the same adresses for the two computers on the other router. Are you sure your computer is setup for DHCP and what are the DHCP settings on the old router?

Assuming something has not gone awry with the network configuration in the ISY, then yes. But it also should have worked with the other router, unless it is actually a different subnet (e.g., you were thinking it was 192.168.1.161 but it is really 192.168.7.161). If the settings in the old router haven't changed, then your computer should pull an IP address from DHCP on the same subnet as the ISY.

I don't think so I have blue, yellow, grey, black, and white straight cables in my setup. The only crossover cables I have are red and yellow and have a sticker on them that say "crossover cable". Without the sticker, I imagine the only way to tell is to look at the wiring of the ends. Of course, as paulbates said, with a fairly modern adapter, it may not even be necessary.

It's not the color of the cable but the way the ends are wired. Look at the colors of the little wires inside the clear plastic RJ-45 connectors. If the two ends are wired the same, it is a straight cable. If the green/white and white/green pair is swapped with the orange/white and white/orange pair, it is a crossover cable.

Assuming that something hasn't gone wrong in the ISY. It seems as if the ISY was still configured with a static IP of 192.168.1.161, it would be showing up in your current router. However, if something has been corrupted on your ISY and the static IP setting has changed, it is going to be hard to access it on any router without factory resetting it. That said, anything is worth a try. That said, you could even hook your computer up to a crossover cable directly to the ISY and set your computer to have a static IP address (192.168.1.x) and see if you can access the ISY that way.

Do you have a recent backup? Looks like you are going to need to factory reset your ISY to return it to DHCP. Also, are you saying the ISY shows up in the portal as connected?