Guy Lavoie

The Venstar T7900 has that capability, and there is a plugin for it. But the plugin itself doesn't have the ability to switch heating mode to auxiliary.

Not for long...

From zero to two solutions...isn't life grand? Really, whatever works for you. I don't think we can say there is a right or wrong way. I usually like to stick to the most adaptable way (that I can reuse in the future). The sockets method is the lowest level, and can be adapted for use with other things like tcp connections, raw, etc. Think of the options you see in the networking module on the eisy.

If you have other routines using fast-ons on other switches, do they still work?

Good luck! Keep us posted.

Well that's the thing you need to determine. That test program is pretty well the absolute minimal program you can have to try this. If you're getting a timeout error on the "recv" part, then the initial "connect" seems to be working, but not getting the response. Try just connecting first. Like this (changes are after the "else" statement). import socket HOST = "192.168.0.145" PORT = 8080 with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s: s.settimeout(2) try: s.connect((HOST, PORT)) except socket.timeout as err: print("timeout!") except socket.error as err: print("error!") else: print ("connected")

Start by sending a hardcoded value, just to test that the plumbing works. Then you can work in your actual data and other details.

I had a bit of time this afternoon and got it tested and working. Here is a python test program that sends "/rest/vars/set/2/6/9" to a eisy at IP address 192.168.0.145. This sets state variable id #6 to a value of 9. Notice the part "Basic cGFzc3dvcmQ=", that's the admin password "password" encoded to a Base 64 value (I used "password" so that you can test that you get the same result, you'll need to encode you own password). You an encode a password here: https://www.base64encode.net/ Let me know if that works! import socket HOST = "192.168.0.145" PORT = 8080 with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s: s.settimeout(2) try: s.connect((HOST, PORT)) except socket.timeout as err: print("timeout!") except socket.error as err: print("error!") else: # send REST command s.sendall(b"GET /rest/vars/set/2/6/9 HTTP/1.0\x0d\x0aHost: 192.168.0.145\x0d\x0aAuthorization: Basic cGFzc3dvcmQ=\x0d\x0a\x0d\x0a") data = s.recv(1024) s.close print(f"received {data!r}")

Oh my, my first computer was a TRS-80 model 1. The best $1000 I ever spent. The things I learned with it, including assembler programming, served me so well for my 40 year IT career.

I learn that way too. It's slow, but the knowledge acquired sticks! Two noobs should be able to get this figured out...

Well let me dig up the sample Python code that I did to do that. I'm still learning Python and created two plugins, in wanting to learn to create a fancier one. I have a code sample that connects to a socket and writes data, and I also have VB6 samples of creating REST commands, so know how to make http GET commands with raw bytes. I'll just need to put the two together... I might have a chance to check that out tomorrow.

Are you able to open a socket in Python, connect to a tcp socket, and send raw data? If so, I can give you some help with what the raw bytes need to be to create a REST request.

The eisy uses unix commands. This will be very different from any controller previous to the Polisy and eisy. As for copying files in and out of it, the "scp" is what's available. Thankfully Windows supports scp. There is no ftp, rlogin, rcp, rsh or any of those in the eisy.

That 5.9.1 has me intrigued. And I'm not alone...

Well wait a bit... Maybe you have another issue that's affecting performance, like something stuck in a tight loop, making it slow. Is the eisy itself unusually hot to touch? If you look at the "summary" tab under programs, does anything look unusual in the "Activity" column? Anything strange like "running" constantly or even "out of memory"? You could try disabling some of the programs that appear to be running constantly, as a test.

Just for fun, I created a scene with a Jasco z-wave on/off module as a controller, and an Insteon wall switch as a responder. It works; turning the Jasco module on and off controls the scene perfectly. So the eisy can certainly use z-wave devices as scene controllers.

If you look at one of your z-wave switches in the admin console device list and turn the switch on and off manually, does it's status update in the admin console? If so, then you could look for the status change using a program, and have the program correspondingly turn the scene on or off.

You mention migrating. From a ISY994i to a eisy? Are you reusing the same PLM or is this a new one?

Yes, you can program the eisy to send a "query" to the IOLinc. This asks the module to send it's current status. I do this with a garage door opener application. The IOLinc is not a dual band module, it's powerline only. This makes it more likely to lose a signal transmission if it activates a motor driven device that produces electrical noise. To poll it's status regularly, you could schedule a bunch of hourly requests, such as like this for every 15 minutes: If Time is 8:00 Or Time is 9:00 Or time is 10:00 .... Then Set (IOLinc name) Query Wait 15 minutes Set (IOLinc name) Query Wait 15 minutes Set (IOLinc name) Query Wait 15 minutes Set (IOLinc name) Query But before doing all that, try activating the gate with your program, then wait for the time it takes the gate to open or close, plus 10 extra seconds, and then adding a query statement after that. This would have it queried after the time that the motor has finished opening or closing the gate, when the electrical noise has stopped. See if that makes a difference.

Here is my idea about how it might all work (just speculation based on what I've read so far). Matter is an IP addressable protocol, so it would likely have a very well defined set of instructions and definitions for generic support. Much like "Class compatible" USB devices that need no drivers. As for physical layer, it supports both straight IP (hardwired and wifi) and Thread, which is a mesh network, like Z-wave and others. Battery powered devices will likely use Thread. Both both physical layer types support IPv6 addressing. Think of it as a type of dual band capability similar to Insteon, though I don't know of devices can act as repeaters across both physical layers the way Insteon does. Thread uses 2.4 GHz frequency, like Zigbee. I saw somewhere that the Zmatter dongle will use the Zigbee antenna for Matter too, which would make sense. So it would appear that the Zmatter dongle could be the equivalent of a wifi access point, but for Thread. Since both physical layers support IPv6, maybe the dongle will create it's own subnet and act as router? Who knows. Straight IP wifi or hardwired Matter devices probably won't need the dongle at all if you don't have any Thread devices. I can't wait to find out how wrong I am!

I had been wondering where "SkyLink" on the box came from. It was the only Insteon product with that.

Well no one has seen it yet, but I would be extremely surprised if Matter support came in the form of a plugin. It just wouldn't make sense, especially with the Zmatter dongle being part of the equation. I expect it to be integrated like z-wave is.

I'd say more than likely. In ISY, everything becomes a node, and get equal treatment in program statements. Even devices that are created by plugins. The notion of scene is also democratized among all types of switches, not just Insteon. You can have an insteon triggered scene also turn on z-wave devices, etc.

How long does the 9V battery last in the winter?

Can you tell if the flicker is being caused by the motion sensor sending out it's rf signal (which would be unusual) or if it's from the powerline and rf signal being sent from your controller to the on/off module? One way to tell would be to temporarily disable the program turning on the receptacle, and see if the flicker still occurs when the motion detector is tripped. If it seems to be caused by the command being sent to the receptacle, do Insteon commands sent to other devices also cause the flicker?