xlurkr

This thing is totally kicking my butt. I've done 11 excludes and includes now, and one hardware reset of the switch (after exclusion #7 or so). I can't seem to get it to behave well any more than 5 feet from the ISY. I have tried putting another device between it and the ISY, and doing a network heal several times, but it's no use. It keeps getting "can't communicate" errors on the dimmer part, but not on the relay. Another weird thing is that several actuations of the relay button can make it connect again - sometimes - but eventually it fails again. I'll probably permanently install it tomorrow, because I really need a dual switch in that box, even if it isn't automated. But if anyone has any suggestions on how to get this thing to behave - other than upgrading my dongle and moving to 5.3 - I'm all ears. @asbril: did you ever try this switch with the 300 series dongle and/or 5.0.16? How far is it from your ISY? -Tom

Updated to 5.0.16C, and the pending updates are gone. I hope they'll still be gone in the morning. The Dimmer node still must be queried, and there are still no options for setting the variables. After I do the physical installation, I'll do a network heal and see if anything changes. If not, that's OK. I only need to be able to set the dimmer on/off. The relay MUST be sensed when manually switched. Someday I'll upgrade to the 500 series dongle and >5.0.16, but the war stories of that dongle with the Schlage locks are holding me back. -Tom

I'm halfway through installing one of these and it's not going great. First, let me state that I'm on FW 5.0.16B, and have the 300 series dongle. After several false starts, I have the set of nodes displayed in the attached image. I can control the Dimmer Switch node, but I need to query it to get it to show the correct status. It also doesn't have an Options button, and looks exactly like an Insteon dimmer, so I'm wondering if the ISY got confused when adding it. The 26.1 On-Off Power Switch can be controlled, and also automatically updates the status. Cool. The Binary Switch and Scene Buttons are blank, but that's consistent with what everyone else is reporting. I could probably live with it as it is now, except that, as the image shows, it claims that updates are pending to everything except the On-Off. It's been that way for 8 hours now. I have clicked "Write Changes" on the dimmer, right clicked and selected "Write Updates to Device", rebooted the ISY, and nothing changes. I can certainly exclude it and include it again (will be the 6th time), and might just try that after posting. I could do a network heal, too, but I'm reluctant to, because I spent 4 hours yesterday adding a Schlage lock, and I'm afraid to do anything with network-wide consequences unless absolutely necessary. Also, the Zen30 is in a temporary box close to the ISY to do the inclusion and setup, and I'd rather not heal until it is installed in its permanent location. Recommendations, anyone? -Tom

I've got 3 battery powered detectors that are compatible with the SB, and one AC powered one (demanded by code) that is not, but is still "One Link". I think that the AC one will trigger the other ones, and maybe one of them will trigger the SB? I'm afraid to test, because I live in a condo, and if all 4 of these go off at once, it better be a real fire. Otherwise, there will definitely be a real home invasion and assault by one of my neighbors. -Tom

I think I read somewhere that the newer models of the First Alert detectors don't work with the Smoke Bridge. That might explain it. - no new compatible detectors available. -Tom

I fooled around with this a little more. Using the SHN Utility, you can see what traffic is generated when you talk to the EZIO. I reenabled the analog input and removed the header so the inputs would float. Pushing the buttons to read AN1 and AN2 in the utility returned small non-zero values, and also revealed that you get the values by sending commands to do a peek on a register - not surprising that the ISY didn't want to go there. It corresponded exactly with the documentation on the SmartenIt website for the EZIO8SA. With my EZBridge, this can also be done by passing XML back and forth. I tested with the same commands the SHN Utility used, and it worked. It's long discontinued, though, so won't be much help to you. However, you might find some RPi or other homebrew solution that would do pretty much the same thing. You "just" need something to connect to a PLM, send Insteon commands, and return the result. Should work with the 1wire sensor, too. Let me know if you want to explore this, and I can help you with the commands if you need help. -Tom

More searching revealed that the ISY doesn't support analog or 1wire input at all. -Tom

I did some searching, and it looks like it's expected behavior that queries only work on the first node, and those queries return any states that have changed. Not sure why there's such a delay in returning the values of relays that I manually changed. Maybe the queue gets filled with all of these bounces between 0 and 255 on the analog inputs. Also, in one topic, there was a warning about changing the operating modes in the SHN utility. It's likely that the ISY sets some of the modes they way it wants when the EZIO gets added. That's a good point I hadn't considered. When I have time, I'll factory reset the EZIO and its PLM, remove it from the ISY, add it back, and see what the settings are in the SHN utility without changing any. -Tom

I'm using an EZBridge to talk to the EZIO. That eliminates the need for a PLM connected to the computer. The EZBridge connects to a second PLM, and I connect to it over WiFi (it's hardwired to my router). The EZServe might also work the same way, and had a built-in PLM, I think. -Tom

Getting weirder. Looking at the ISY log, I can see that queries on any nodes other than the first one trigger no activity. Queries on the first node usually return one or two entries for the analog inputs, which bounce back and forth between 0 and 255, but no other values. While doing that, I occasionally turned one of the relays on and off. Subsequent queries on the first node would eventually return a status change on the relays, several minutes after they had changed state, mixed in among the more frequent analog input status changes. I'm pretty sure this isn't how it's supposed to work. I'm going to unplug and/or reboot everything, and possibly even remove the EZ and reinstall it, since I'm not using it for anything right now. Assuming I can get consistent results on the inputs, I'll submit a ticket. I might also experiment with creating links for the inputs. Currently, none have links. Throughout, the relays have always turned on and off instantly, and the status has been accurately displayed. One positive note. -Tom

No need to, I think. If I query the analog inputs from the SHN utility, I can see the PLM blink. If I query from the ISY, no blinkee. That explains what I'm seeing. I can enter a support ticket if you want. I think I'm in a better position than you to document and test, since I have the SHN PLM and my relays are working. -Tom

Mixed results. In the SHN utility, I can clearly see random (noisy) values returned from the analog inputs when they are allowed to float. When the header is connected and they are grounded, I get 0 or 1. However, queries from the ISY are not tracking. In fact, they're not consistent. I have two laptops connected, and on one the queries return nothing. On the other, queries return 100% every time. I'll reboot the ISY, power cycle the EZ, etc. and see if I can get the analog inputs to return a reasonable value when queried. -Tom

I did manage to fire up the SHN utility. As I suspected, the analog inputs are now set for threshold, and the broadcast is turned off, so I shouldn't have been surprised not to see the PLM flood when I took off the header. I don't remember setting it up this way. Maybe it reset itself. I'll turn both features back on and see what happens. Also, there IS a checkbox for the 1wire interface in the utility, so that probably needs to be set if you have any expectation of seeing something on the ISY. And I think you are right that it only supports 1 device, and I believe it only supports the Dallas temp sensor. -Tom

I just hooked mine up. It's controlling the relays just fine - I can hear them clicking when I turn them on and off. I'm on 5.0.16B, and using the original SimpleHomeNet PLM. The inputs I'm not so sure about. The analog ones are configurable, so I'll need to fire up the SimpleHomeNet program on my old Windows laptop to determine how they're configured now. I suppose I can test them with a 1.5V battery. I remember the last time I had it connected it was flashing the PLM light constantly until I rediscovered that you can't leave the analog inputs unconnected - you need to wire them to ground, which is how they are now. But I removed the connecting block to let them float again, and there was no activity on the PLM light, and queries never returned any different values. Weird. BTW, I'm not sure you're right about the 1wire temp sensor. The ISY shows 7 inputs: 9 through F (in hex). The first four are digital, and the next two are analog. That leaves "F", which is probably the 1wire input. I don't have a sensor to test it with, though. -Tom

Teken Rocks. Indeed. -Tom

And I can verify that if you try to log in to your account on the website, the only option is a button that redirects you to the portal. -Tom

@Michel Kohanim Is there anything you can do to get the AC (and REST calls, etc.) to reflect that the STATUS of a dimmer is 100% if it has an on level of less than 100% (or is currently at <100%), and is turned on a second time to go to 100%? If not, OK, I'll use lilyoyo1's workarounds. But I thought you might want to think about eliminating one possible source of STATUS being inaccurate, if it's not too difficult or problematic to implement. -Tom

I have been making some changes lately to my ISY, and just noticed something. I have several dimmers and KPLs that will turn on to the on level (let's say 75%) when first manually switched on, then go to 100% when switched on again. Not sure if all Insteon dimmers do this, but probably. Anyway, in the AC and UD Mobile and maybe all other interfaces (tbd) the status of the node remains at the initial on level after I do the second manual on actuation. Is this by design? Even weirder, if I dim it manually (up to 85% let's say), the status reflects that. Then if I manually press on again, the light goes to 100%, but the status drops to 75%. Sorry if this is well known or a defect that has been fixed. I'm on 5.0.16B. I was trying to create some scenes with levels of less than 100%, with lights I couldn't see from my location, and the difference between the status as reported by the AC and the actual light levels was messing me up. -Tom

@simplextech: Do you know if ZLink has their own switches that are the same as the 200 series of HomeSeer? The naming and feature set of the ZLinks look more like the HomeSeer 100 series. -Tom

FWIW, it is stories like this that are keeping me from upgrading to the 500 series board and > 5.0.16. I have no need to upgrade, but I'd like to stay current if possible. I only have a few Z-Wave devices, but I don't want them to stop working. -Tom

When I was having my problem, I copied Michel's command and pasted it into a ssh terminal session on the Policy. I got the HTML response, and bash choked on it. Two days later I did exactly the same thing, and it updated correctly. I would say that the server destination has occasionally been borked. Not sure how or why, but this isn't just about browsers or incorrect paths. -Tom

This morning, the curl | bash command worked, and I successfully upgraded to 12.2. The NS installed correctly. After initial configuration, it's working fine. Thanks to all for your help, especially Rob. The most logical conclusion is that the current version of this NS requires version 12.2 of the OS. I hope 12.2 doesn't break any of the other NSs, but I suppose if it does, the authors will fix them over time. -Tom

Michel: It is working this morning. It was not yesterday. Curl was returning HTML, not a bash script, and bash was choking on it. See my first post in this thread. I don't know what changed, but it was broken, and now it's not. Thank you. -Tom

Ticketed. -Tom

Ticketed. -Tom