Man, I am frustrated, it looks like my Insteon HUB died, when I flip switches I see them in the logs, but no lights change when I control them from openHAB. This is a major problem for me because I have 135 Insteon switches in my new house. I really don’t want to switch, but if my HUB is dead, this would be the 2nd time one has died on me.
I guess my question is, if I should swap all my switches for Z-Wave. If so, is it worth going Z-Wave Plus? My biggest concern is that I don’t think you can configure z-wave with config files yet in openhab 2 and I really don’t want to point and click.
I also am thinking about switching to z-wave, but I don’t have close to that number of switches. I am looking at HS-WD100+, how is openHAB at supporting that dimmer?
I don’t have any real experience with insteon. Zwave has its issues as well. I have had a few switches and outlets die. I use a Vera lite as my controller and it has been reliable for about 3 years. It was touchy about plugins. When I moved to oh as the rules engine things got reliable.
My biggest concern is scale. I have 45 z-wave devices already if I add 135 more will things start to break. Yes I know that wish mesh, the more nodes the better, but that breaks down at some point, just don’t know what that point is.
Have you tried the USB Dual-Band Adapter (2413U)? I am using it with a RPi 3 installation and 9 Insteon devices since about 4 months without any issues (might not be long enough?)
Well, a single zwave controller has a limit of I think it was 232 nodes. 8 bit minus something.
You can use multiple controllers, of course, but since they wouldn’t be acting in a coordinated manner, this would reduce the RF spectrum efficiency, so having a single one is the better option.
Going ZWave Plus means better range so less message routing (= reduction of radio bandwidth), so it’s a good idea, but it’s no must. Either way, most if not all new devices are ZWave Plus today anyway.
On OH2 configuration, you’re worried about some 100 clicks, but you don’t care about the effort to exchange 135 devices ?
Interesting
I’ve had no issues with my PLM that I’ve been using for a few years now, other than the known issue where you need to replace the capacitors as pointed out in the known limitations: Insteon PLM Binding · openhab/openhab1-addons Wiki · GitHub
Does the capacitor issue apply to the USB modem though? I thought that was specific to the serial PLM.
I had my trusty 2012 hub die just recently. I had a spare USB PLM on hand (for just this eventuality), amd was able to switch everything over from the dead hub to the PLM using houselinc in just a few minutes (well an hour or so).
I then picked up a 2012 (refurbished) hub on eBay. I currently have both running in parallel (with another spare 2012 hub on the shelf).
I have 80 Insteon devices, and given my experience with zwave (22 devices) no way in hell am I giving up my Insteon devices. The best thing about Insteon is that you can configure everything to work without a hub/computer. Zwave, not so much (you sort of can, but not really).
So when the internet/computer/hub dies, the basic functions still work, you just loose the fancy computer based stuff.
From a WAF point of view, wall switches are just supposed to work. With Insteon, they always do.
And I know you can configure Zwave in a similar way - but who really has their Zwave devices set up like that? Because it’s hard to do…
I have 120 Z-Wave devices. It works finally very smoothly, but this was a long way and I was frustrated a lot of times … As mentioned earlier in this thread Z-Wave has issues too.
From my experience there are 2 main sources of problems, one concerning the Z-Wave inclusion process and one concerning the reaction to timeouts of the Openhab Z-Wave binding.
The inclusion process with Z-Wave devices is unfortunately a weird thing. It is different for every device, requires patience and even when everything seeemed to work and the new device is displayed, it does not mean that it will work. Very often I had to reinclude devices twice, triple…even worse for battery powerded devices…
Timeouts: The OH Zwave-Binding (OH2) tries 3 times to reconnect to a not answering device after a timeout . Each timeout makes the complete binding to hang for 5 seconds. 3 times = 15 seconds. So very few problematic devices will stop your complete network. I am not sure if other software alternatives handle this better, but the problem might be illustrated by my own experience:
By default, every device is polled by OH2 every 30 minutes and this on ALL poosible Channels for the device according to Chris’ Database. Many devices are listed there with lots of channels (e.g. my Qubino Dimmers with 16(!) channels, although I only use 3 (Dimming, Power and Conumption reporting). This means 16 polls every 30 minutes multiplied with 120 devices = 3.840 polls/hour (=more than 1/second). If one fails, 15 seconds are lost for everything, you have hangers. And now in real life, some devices do not have all the endpoints as in the database and always hang, others hang sometimes and so on. At the beginning, OH2 was not usable at all.
After reading hundred thousands of lines of debug logs I started understanding the underlying problems. I then reincluded some devices, scrapped some, reduced polling to 24 hours per device and so and so on. Still, every update from OH2 or snapshot can harm and bring back problems.
So, if you invest huge amounts of time, a large Z-Wave network may be very good. But not out of the box…
On the other hand:
The backup and restore function of my Z-Wave controller (Aoen Z-Stick Gen5) is excellent. So the risk of loosing everything by a controller breakdown is a non issue.
And: The mesh network works fine although I have a lot of thick concrete in my new house. I was worried about this at first, but meshed networks ( I use Z-Wave and Sonos) work fine.
I guess I can check my caps, the odd part is that I see all events from my hub, but I can’t send any events. I have the same issue with the iOS insteon app so really don’t think it is a openHAB issue.
Are you saying I can move from a HUB to Serial PLM without re configuring my 135 devices?
Totally agree with you on the Zwave this is why I invested so much money in Insteon. I understand I can have more then one switch work together with association groups and not need openHAB running, but still read about issues with zwave with updates.
Huh? Everybody but you, supposedly. You wired your lights and switches to the ZWave actuator, didn’t you? So wall switches always work. Or don’t you have wires between your switches and lights in your house?
You can also have a secondary controller connected to openHAB or as a portable remote to work without the openHAB server.
And I don’t get the point why that’s of importance. Is your openHAB crashing day by day or what ?
As long as you invest time and testing efforts into a backup & recovery concept for all of your control units (i.e. the openHAB server and the ZWave controller and the Insteon hub), you rarely hit the situation that you need this ‘works serverless’ capability.
And that backup part, you MUST get that right anyway. While not essential to survival, too many functions depend on a working openHAB server already, don’t they ?
So while you might not be sitting in darkness, you (and your wife) will still be pretty annoyed from a server outage.
Btw, I just went through a similar thing. The symptom was ZWave commands starting to queue up, slowly driving the whole system to a halt.
I thought my RaZberry zwave controller card was broken. In the end it turned out to be corrupted Linux journal files that must have been around for a while, and (Murphy…) I cloned my SD card including that corruption, so I encountered the same problems with most of my backup cards (sigh!).
Anyway, now I know my emergency recovery plan is working, including backup & restore of the zwave network config inside the controller.
Many of my lights don’t have wires between the switches and them, and none of my sensors do. My point was that with Insteon, you don’t need a hub or controller or secondary controller for this all to work as normal.
And with the switch to Openhab2, yes, OH was failing to start every time there was a “breaking change” in OH2, or a refactoring, or change in the directory structure…
My point was that you don’t need a backup strategy with Insteon, the basic functionality works without a hub, or OH or anything else. So if your hub or controller or OH dies, the fallback is automatic, and 95% of things continue to work as normal. All you loose are the rules based functions and remote connectivity.
With Zwave, you need the central controller just for things to function. If it goes bad, you loose everything, remotes, sensors, wireless switches etc. and you can’t back up and restore a Zwave controller (not without a lot of effort anyway).
Don’t get me wrong, I like and use Zwave, but for basic functionality I think Insteon is more reliable.
[quote=“Nicholas_Waterton, post:12, topic:25590”]
Many of my lights don’t have wires between the switches and them, and none of my sensors do.[/quote]
Well, that’s … let’s call it exotic, so I don’t need to tell you it’s your own fault if you build your home like that That does not have anything to do with ZWave or Insteon or any competing technology in the first place.
And it only applies to your uncommon setup without wires between lights and switches. Anyone else to have those wires will have their lights and switches work even if OH or the server fails, and even so when there’s problems on the RF side (lack of radio connectivity or the opposite, too much thereof, i.e. ‘phantom’ signals).
Of course it’s fine to prefer using Insteon in your situation, but you can’t blame ZWave for not being the best choice in this very specific setup, can you ?
Sensors, huh? They won’t work properly without a control unit anyway. To link sensors to actuators without having a central compute unit inbetween to apply a useful logic based on the sensor’s signal rarely makes sense. Maybe in a movement detector - light on situation, but that’s the only one I can think of. And remember we’re not talking about regular processing but about the fallback use case that you want this to work even in the rare case that the server is down. And even then, you’re wrong here. You can actually setup ZWave to work serverless like that.
Same with ZWave. Have two associations, one to the controller and another to the actuator.
If your products can’t be setup like that, that’s not a ZWave issue but one of the specific device you’re using, so it’s not fair to say Insteon can do it and ZWave can not. It’s rather that you chose an inferior product.
[quote=“Nicholas_Waterton, post:12, topic:25590”]
My point was that you don’t need a backup strategy with Insteon, the basic functionality works without a hub, or OH or anything else. So if your hub or controller or OH dies, the fallback is automatic, and 95% of things continue to work as normal. All you loose are the rules based functions and remote connectivity.[/quote]
Ouch! To have a fallback for most critical functions like lighting never hurts, but it’s plain wrong to claim you don’t need a backup strategy then.
You need to have a proper backup strategy anyway for a multitude of reasons. Just think of all the rules based functionality that won’t be available when OH fails. You might be at a beginning stage where you control little through OH and feel this does not do harm, but the more advanced your setup becomes, the more important it is to have that rule based functionality available.
My point is: get your OH (+ZWave+whatever) backup strategy right. You can keep your Insteon fallback, but you won’t need it nor rely on it any longer.
On backing up/restoring a ZWave controller, sure you can! Well there, too, might be you have a bad product. But the most common controllers (Aeon gen 5 stick and RaZberry/zwave.me) DO allow for this. Working that out is exactly part of what I meant when saying ‘get your backup strategy right’.
How many devices do you have in your network? Anyone with 175 or more devices? That is what I will have if I merge my 135 Insteon switches to Z-Wave. Also, I hear it’s possible to configure Z-Wave with .things in the dev branch, but I can’t find any documentation on it.
Well, I myself would refrain from such a big move, but not for technological reasons, just because of the huge (physical, time and financial) investments that it requires.
But then again, that of course only depends on how frustrated you actually are with the status quo.
I assume that your question is none of particular urgency as you wouldn’t do that in a single rush but rather start to subsequently replace devices anyway, so it’s merely the question if you should start that process now, right ?
From that perspective, i’d clearly decide to go ZWave, less for technology reasons rather than because Insteon is a closed, proprietary system, and in the long run, proprietary systems have big disadvantages. You’re just getting hit by some of those: You have no choice other than to buy another hub. What if they don’t deliver or decide to no longer sell this one? What if they have a critical software bug and don’t fix it? And what if the vendor goes bankrupt?
Sorry I didn’t mean to blame you for a decision of the past nor to start a discussion on this. It’s just that it seems you’re at a branching or turning point where you should consider these things.
Once I had decided to move, I wouldn’t hesitate because of network size or the need for point-and-click configuration. There’s no reason to be afraid of the number of ZWave devices.
If your ZWave network works today, it will continue to work fine as long as you stay well below the device count limit (232, that is), which is what you do. And for comprehensiveness: that’s no dead end/hard limit either as you can have multiple ZWave networks, you just happen to need one controller for each of them.
In the end (all Insteon devices replaced by ZWave ones), it’ll work even better than today as you will no longer have two systems competing for the same radio frequency. That might be a theoretical advantage rather than a practical one, then again, I do know of people that had trouble with that sort of competition in some situations, myself being one of them.
Either way, for sure it will not be worse than it is now.
PS: and again, to everyone:
get your backup right! Think of your OH server, but also think of the ZWave network. Get the Aeotec tool to backup your ZWave stick, and test the procedure, including a restore to your backup HW.
I am not looking forward to a big move, but this would be the 2nd time I had to reconfigure 135 devices. It takes a LOT of time and if it is something I am going to have to do regularly I would rather just suck it up and swap out the devices.
I understand what your saying about closed vs open, but I chose insteon because it was dual band, so far it has been very reliable in a large network other then hubs dying. Lots of people have said don’t worry about a large z-wave network, but so far I have not actually talked to anyone that has a large network. With my small 40 device z-wave network I have had problems with one or two bad nodes taking down the whole network.
The whole network, really? There’s multiple potential reasons. Please try to make proper distinctions here.
You can have bad devices to misbehave (say, flood the network with messages during installation) because of firmware bugs or bad default parameters. As there’s more intelligence in the devices themselves than with Insteon, the risk of devices interfering on a functional level with each other is a little higher (note I’m not talking about the transmission layer, so that’s no ZWave problem, but you easily attribute that to ZWave and blame it).
And the version of the ZWave openHAB binding you’re using is of particular importance. Strictly speaking, you can’t attribute its weaknesses (if any) to ZWave as a technology either. And of course that’s a moving target. If you did happen to decide to switch, by the time you are done with your exchange project, the binding software will probably have changed several times.
I remember that ZWave network healing was disabled for a rather long time in the binding. Healing is essential particularly for a large network to work stable and particularly during a phase where you move or add many new devices.
I actually don’t even know the current status on healing, and it’ll depend on the OH branch, too (1.8.3, 2.0, development branch). @chris, would you mind to give a status on this ?
Dang, my hub (2245-222) went today. No lights - probably the capacitor problem so I will try replacing C7 rather than relinking and reprogramming a new hub. Too bad you can’t but a new hub and have it “spoof” the old hub - or just have a transfer mechanism that is automatic. Or just have hubs that don’t fail so regularly. Or…
That does not have anything to do with ZWave or Insteon or any competing technology in the first place.