Broyd

The Z-Stick firmware package comes as a zip file containing the firmware plus the software to run the Z-Stick. You unzip the downloaded file to a folder (recommend you not use your desktop). The .exe file may need to be renamed to .exe. The readme file will tell you this. Basically you plug in the zstick, start the .exe and using the software user interface, connect to the zstick. Then you put the zstick into join mode and press the action button on your zwave device. Then wait until it’s found this device and has become stable. In the right pane there is a firmware upgrade tab and you select that and start the firmware upgrade. This can take a few minutes and you’ll see a upgrade successful message. I believe you will fully have to remove the device from the ISY and add it to the Zstick to do a firmware upgrade. I have always done it this way. I found this link a while back but I haven’t tried it yet. https://www.activeautomation.co.nz/boards/topic/3/adding-aeotec-z-stick-as-a-second-controller-to-an-existing-z-wave-network The link for Zensys tools in that post seems to be dead. Hunt for it on Google or I’ll save you that effort. Hang onto this download! Zensys has removed all copies of that file! http://www.axialcontrol.com/zensys-tools.zip This is one of the last copies of this file I could find.. The Zensys Tools looks similar to the firmware update tool but actually does different stuff.

I installed the new dongle this morning and on the surface, everything seemed to be perfect. I only have 3 Z-Wave devices in the system right now; an Aeotec doorbell and 2 Multisensor6's. I could ring the doorbell and get sensor reading from both MS's. But when I queried the MS6's the system stayed busy for 84 seconds and the device communication events were horrendous. See the attached log rather than me dropping 705 lines into this post. In addition there is nearly continuous traffic going on between the MS's6 and the ISY - and its all the same sort of messages as in the attached log. ISY-Events-Log.v5.0.13A__Mon 2018.07.16 11.58.26 AM.txt

Hi MWareman I have noticed that all of your zwave device displays [ZW-SHOW ] start with [UZW-CMD 51 ] [ZWCMD cmd.51] Where does that UZW command come from? When I do one of these displays (Z-Wave > Show information in event viewer) , it starts with [ZW-SHOW ] . Am I missing something when I get this Z-Wave device information? Thanks!

I just picked up the new dongle ... I must say I was disappointed with the packaging; there was no antistatic bag and it was in a plain bubble envelope - nothing to protect it from crushing actions. Just saying.

Hi Michel, One more question on shipping. Are you (UD) still locked into Fedex or UPS? The last time I ordered this dongle it was going to cost me over $20 to ship. I got it from Orchestrated Home who used USPS and the charge was less than $5. The package was well packed. Your introductory price looks great but expensive shipping would ruin it.

A question Michael. You say this is beta, does this mean the hardware will change once the final product is released or would this be a firmware upgrade?

I just upgraded to 5.0.13 and when I web log into the ISY (UD Ajax) all of my Insteon devices show the left and right ‘power’ buttons. But the left button is ALWAYS green no matter what I do. The status does change from 0 to 100 present when I press the gray button that used to be red but that button never lights up red when a device is powered off. Is this a bug? I certainly does not easily visibly reflect the device status as it did in 4. Thanks for checking The Z-Wave devices all work the way they did previously, just Insteon devices are affected.

Sorry, this would have given you wrong info ...

Hi MWareman, I know that we are dealing with two values that are different ... however ... When I use a browser and issue: http://192.168.1.25:37190/rest/nodes/ZW006_1/CLITEMP I get the following response: <properties><property id="CLITEMP" value="7310" formatted="73.10° F" uom="17" prec="2"/></properties> And in the event log level 3 I get: Tue 05/30/2017 09:45:46 AM : [ZWAVE-PROCESS ] Process value Sensor type=1 uomId=1 prec=2 Tue 05/30/2017 09:45:46 AM : [D2D EVENT ] Event [ZW006_1] [CLITEMP] [7310] uom=17 prec=2 Tue 05/30/2017 09:45:46 AM : [ ZW006_1] CLITEMP 7310 (uom=17 prec=2) This suggested to me that the value retrieved by the ISY was an unformatted integer and that the ISY was supplying the ". ° F". Given the properties and event log above, is that not a reasonable assumption? The property for the humidity, which is an integer is: http://192.168.1.25:37190/rest/nodes/ZW006_1/CLIHUM <property id="CLIHUM" value="37" formatted="37%" uom="22"/> To me, prec = precision = 2 for the temperature and is missing for humidity. My guess for "UOM" is "unit of measurement".

So I have been able to test the network resources REST function. As you suggested KeviNH, the value returned DOES contain a decimal point, even the RAW data. (wouldn't it be nice if raw meant RAW?) I would suggest an additional keyword ... unformatted I was able to show that the REST function works by using the CLIHUM variable which is an integer followed by a % sign. The value returned by specifying raw is just the integer - and that was successfully stored in the variable. I guess (if I get desperate) I could use larryllix's Raspberry Pi Python code and have the ISY send the data to the Pi and have the Pi reformat it and send a REST back to the ISY to store it ... This would be OK; I'd learn a lot

Hey! I have read enough posts on this forum to know that you both have contributed immensely here. (And hopefully will continue to do so). @larryllix, I have been going over your Raspberry Pi Python code for an HTTP server and am definitely going to be making use of it for the control of a Hunter ceiling fan having 3 speed windings, reverse, light on/off, and dimming capabilities. The 3 windings avoid the very annoying magnetostrictive hum associated with dimmer controls, and I need a sub-second response for the on/off function of the light to avoid activating the dimming function. It will be ISY-994i > HTTP > Raspberry Pi > GPIO > homebrew isolated interface > 'off the shelf' slightly modified Hunter remote fan control. Your code contribution here has been invaluable. @KeviNH, Thanks for taking the time to read my original post; this is something that I need to be careful to do as well. In so many forums, people jump in without accounting for all of the relevant information before making a post. Having read Chris Jahn's post about setting Z-Wave parameters using REST, I was starting to think that might be a method that would work. I was hoping for a less circumlocutious method but I guess being still at 4.5.4 I am stuck with that. I will be trying your post above. It's good to know that with versions 5+ that some of these capabilities are available. And some point, (likely a beta 5+) I'll make the leap Thank you both again

Thanks larryllix, I was hoping to be able to grab the actual temperature sensor value and store that in a variable. For example, if the temperature reading is 71.20°F, the raw value seen in the event viewer is 7120; I'd like to get 7120 into a variable, along the lines of ... or ... this is what I'd effectively like to do. $iVariable = ${sys.node.ZW006_1.CLITEMP.raw} If some sort of testing loop is required, maybe I'll give up on the idea .

Is there any way to copy the temperature value from a Z-Wave Multisensor 6 into an user accessible ISY variable (integer)? (raw doesn't matter). You can see this raw data in the event viewer on level 3 when the MS6 transmitts the temperature to the ISY. The temperature value is displayed on the Multisensor panel when displayed in the admin console or on the WEB udajax screen from a browser. The MS6 sensor variable reference is: ${sys.node.ZW006_1.CLITEMP.raw} I am at ISY version 4.5.4. I have the network module. Any insights into this will be appreciated

You want the doorbell unit. It is by far the most useful.

This relay board will do what you want. 10 amps per circuit max. If you go this route, make sure you order the controller board PLUS the relay board. They can be ordered individually. You will need to buy the ISY network module. I wrote up some instructions in this link: http://forum.universal-devices.com/topic/21533-can-you-use-variable-substitution-in-a-network-resource/

Hi larryllix, There IS a longitude entry field. Just stretch the right hand edge of that panel by a few pixels and the longitude field will show up. I bitched complained nicely about his absurd behavior a while back but noting has been done to date. It is about the same level as that idiotic and mis-informative misleading message saying Internet Access: disabled in the Help > About panel ... What has worked for me: 1. Find your latitude and longitude 2. Press change location and choose Custom Location 3. S--T--R--E--T--C--H (did anyone notice?) the panel so that the longitude entry field is displayed. 4. Enter your Lat. and Long. 5. Set your timezone offset to your STANDARD TIME offset. Canada-Pacific is -8 hours. 6. IF your area uses DST, then pick Daylight Saving Rule > US-Canada (or what country applies). Otherwise set it > Off 7. Save Setting your lat and long gives you much more accurate sunrise and sunset times than picking a city - which in my case is almost a full timezone away. (Note:- The red 'X' in the upper right corner of this panel does not work even though the red 'X' has been the standard for closing panels since the beginning of time ( well maybe not quite); you must press 'Cancel' or 'Ok'.).

Thanks again Teken. How on earth could those options be configured then?

Thanks Teken! Great information. Obviously the ability is within the bulbs capabilities. If you used HouseLink on a PC with a USB PLM, could you access those features, set them as required, and then move the bulb to your ISY-994i system? "This is up to UDI to follow the API and enable these features so the end user can access them." I think this is a serious omission ... just my opinion ...

Hi Teken, Can you point me to the documentation that describes these two different behaviors? Is there any way to set these behaviors without using software to accomplish it? This seems to me to be a pretty serious omission in the settings for these devices. It would certainly be a no-go limitation for me in terms of acquiring these bulbs. Thanks for pointing this out.

That was eBay USA. www.ebay.com Search for: 199AX-14

On eBay item 331343878398

Not enuf detail ... You want to control 480 volts at what amperage ... but how: on/off or dimmer? What control voltage will you have available: only 480 volts AC 60Hz or do you have 120V 60Hz AC? What about an 120 volt 60Hz Insteon on/off module powering a 120 volt relay rated for 480 volts? I don't believe there is any Insteon product that can handle that voltage directly.

A dry closure is just a simple on/off switch such as a wired unlighted doorbell push button (momentary) or a simple wall switch (continuous). Is your existing doorbell chime unit battery operated? If so, the 2n2222 setup would very likely work. If the chime unit is AC powered, then you will likely have power isolation problems that would occur between the AC chime unit and the IOLinc. Isolation problems could destroy both units. I expect you will use the ISY to ring other chimes by programming, not the IOLinc relay.

I don't know of anyone trying to supply a voltage to the sense input. Normally the sense input is connected to ground through a contact closure or an optical isolator such as is used in the insteon doorbell/ telephone ring kit. I suspect the sense terminal will have a voltage on it with respect to the ground terminal and when the sense terminal is connected to ground through a contact closure, a few milliamps will flow allowing the closure to be detected.

Sorry for the delay stusviews, I hadn't looked at this thread in a while. Yes, I do have 220/240 volt breakers. For 40 amps or less, the breakers consist of two half height breakers riveted together with the trip/reset toggles tied together with a pin. But there is no internal connection. The breakers larger than 40 amps are two full height breakers bonded as above but they have a bar bonding the toggles. See THQL and THQP breakers.