larryllix

Metric or Foreignheat make no difference to ISY or io_guy's NodeLink or VenLink. Temperatures are just numbers to be interpreted by the end user in whatever form YOU choose. Depending on C or F selected in ISY it only assigns the correct suffix to the number in notifications etc.. In the serious world of data acquisition values are not sent in engineering units but in bit counts to take advantage of the best resolution available with the hardware in use. IOW if you have a 16 bit channel you don't send attempt to send the result of a 10 bit A/D conversion down the pipe. You attempt to send the best resolution you can to take advantage of the channel resolution. If this means a transducer with a range of 10 degrees to 20 degrees is represented by a 16 bit A/D converter then 0 counts = 10C and 65535 = 20C. The end user has to scale the bits and add the zero offset to achieve engineering units for the human to look at. You wouldn't have equipment massage and manipulate a raw data value and then give it to another piece of equipment to rescale it down or up. Resolution accuracy can be lost each time. This become evident in many Insteon analogue channels. The 2441ZTH converts it's temperature measurements to C or F and then ships them out Insteon in a 1 bit - 0.5 degrees format. Any further resolution available from the A/D temperature measurement is lost regardless of what the end user wanted. Compensation scales, calibrations and/or end user scaling/offsets could have been done to increase accuracy but it's too late once the truncation has happened. Having said that the Insteon analogue channels can be very limited in bits.

Stuffing the result in a variable can trigger any program to run and cause anything to happen that ISY can perform. Do you understand the difference between Integer and State variables? I have no Zwave modules but I would be sure their values would be usable for variable substitutions in V5. If not yet they will be soon and that means you can set your variables via Rest calls and work from the values from the resultant triggers in ISY. Are you familiar with the Network Resources and how they work as well as variable substitution? Maybe there is some waiting time yet for Zwave modules but it will come. Variable substitution is new in network resources but has existed in notifications for some time now. If you are programming familiar then it shouldn't be too hard to create a series of Zane input module programs to get values into a variable and massage as needed. Later when advancements are made just swap out your modular code for simple methods available.

A program should be easy You would need a scratchpad variable and a finished product variable. Set them both to one decimal point of precision (v5) If the temperature_reported < 999 (must be enabled to trigger on every change) Then scratchpad = temperature_reported scratchpad -= 32 scratchpad *= 5 (for v5 with 0.1 precision) scratchpad */ 50 (if using v4 for temp x 10) scratchpad /= 9 finished = scratchpad Else -- The Insteon 2441ZTH reports in C just fine. There is an option in ISY to report in C at bootup time. Can't remember how to get access to it though.

If you have reformatted the SD card I see no way out except to contact UDI support.

Just to add more fuel to the evidence. Case in point, I have ten active Insteon MS units and have never experienced an All off/on in two years now. I have experienced massive retries from MS units that get no response and would venture to say, without testing to back this up, that multiple retries don't happen once the MS units are directly linked to a Switch link or other Insteon device that acknowledges the command send out, and no ISY intervention is involved. My suspicions are that this "signal clash" is a problem with the serial port driver in ISY not handling Xon/Xoff or other control characters in the data stream from the PLM. As I understand it, the serial port is a proper three-wire EIA-232 signal protocol and signals inside of other data packets can be hard to handle without problems. Buffer overrun is usually the result and erroneous data can be sent if not handled correctly at either end.

Q? Do you have Insteon motion detectors?

With my X10 system I always used a time of about 4 minutes in the MS units. My programs would be set to cut this time short to 30 seconds, 1 minutes, or 2 minutes, always faster, The X10 Off in the MS (not avoidable) would act as a backup signal to insure the device turned off. The programs just shortened the time based on logic conditions. Of course, and I still do it with Insteon as well, I have a 4:00 am program that shuts everything off for the just-in-case scenario.

A lot of effort went into to reverse engineering the protocol levels. This is awesome and could help future developers to make use of Insteon equipment. Disputing a "white paper", as gospel, demonstrates confusion. It is never intended to be a spec for a product, only a concept. However, it does show some laziness and/or deception, on Insteon's part, possibly to protect their engineering time, since patents are not effective.

Here are a few screen shots of network resources tat operate my Hue bulbs. The left Network Resource is bulb specific while the right is generic and operates any bulb. The reason I do not use the generic version right now is rapid firing commands to Hue devices can get the buffered data out of sync with the desired operations. This is an ISY built in caching style currently, that does the variable value conversion at the Ethernet send time, instead of the ISY PLC command time. Command data can get crossed up if the variable is changed in between times. The workaround is individual bulb operating resources s this result in quite a few of them or injecting time delays ....yuk. This is to be made an option in order to fix this, in v5 later releases, and could eliminate many resources needed to operate bulbs in rapid fire or apparently simultaneously. This is quite easy to set up for noobies by just copying this and asking for help here. The variables referenced are setup for a generic bulb (right) and a specific bulb (left) and are comprised of Hue, Brightness, Saturation, and Bulb Number (for the generic resource only)

The ISY works well with the Hues but you need the Network module and there is no feedback to ISY to verify what state they are currently in. It's a one way ticket from ISY out. You need a Hue Hub to make Hue bulbs or strips work. It's the WiFi to ZigBee bridge and is also required for Mobile Phone apps, Some of the disco lights to music sync ones are cool. The hub has a small walwart PSU and required wired Ethernet. From ISY you can send any colour, brightness, ramp speed, saturation to any bulb using the Network module and mostly English commands in each resource. It's pretty easy once you do the first one. I will try to post some pictures of Network resources but it is late right now. Hue bulbs have a very good and easy interface but their yellow, green, blue colours suck. I understand their RGBWW strips and some newer bulbs are improved but have a good study of their colour palette and some don't really exist. Hue API.doc

This is for the Hue bulbs only, as I have no Hue strips. Via a network resource I can turn the Hue bulbs on with any colour or brightness I desire. They don't go white and then change. They turn on with the selected colour. If I turn off the bulb feeding switch on the wall then repower them they will come back on immediately to full brightness and what looks like about 2700K. You have to reset them to whatever colour you want after you reapply power to the bulbs. I believe this is a copy of the old X10 concept to defeat the idea that non-tech users have to have a mobile device in their hand, run an app, and then turn the light bulbs on when entering a room, so they installed the switch flick off and on to turn them on. The negative is after a power blink all your Hue lights are on in the middle of the night. ISY to the rescue! One of the first jobs my ISY does, upon power up, is to turn off all the Hue bulbs. In the middle of the night I have to wait a few minutes but ISY does it, eventually after it reboots. Saves getting out of bed or coming home after the Hue bulbs have been on all day, or all week. There is no feedback to ISY so you wouldn't be able to detect them on remotely either.

Anytime you connect a device across the two phases/legs, to get 240vac, you will need a double pole breaker. With two single pole breakers one could trip without the other and/or you could turn off one and start to work on the wiring with the other phase voltage still alive.

Without reserving that IP spot in your router your router can assign a duplicate device to the same IP address at any time. Last time I played with HS2 ISY was just a dream and the Hub interface was a rough hack. ISY had better conditional handling.

This sounds like your ISY IP address may have changed on your LAN. Do you have the ISY IP address locked down in your router ?

Variable usage is exactly the same except you compare to a variable instead of time or wait for a device to send a command. State variables can cause triggers and Integer variables are only for filtering conditions.

Perhaps the admin console has just timed out and his icons and summary page are just not updating as happens frequently to most of us.

ooops.... OP reports he has already done this and the program tree thing...

Expand the whole program tree structure and watch the icons may help also. This is dependant upon states of programs changing though.

The time period causes triggers at sunset and sunrise+30 minutes because evaluation is triggered by the time condition nodes. However, the time conditions are also evaluated any time of the day when the logic is triggered by the MS sending an On signal. This is when the time nodes act as a conditions. Between the times the logic evaluates as true and runs Then. The MS Switched Off is not a trigger in this logic because it is a different signal and unrelated. Most If lines act as evaluation triggers and, as well, act as condition filters.

I keep a Canadian to American conversion thesaurus under my walker at all times too.

I have had problems with same labels also. Some actually became operated incorrectly and I am not sure where some happened to get crossed. I name all my devices uniquely now in a manner that allows them to be sorted out for viewing in MobiLinc. It's a problem with some software using folders and some not. Despite being in different folders sorted under distinct rooms names I use labels like MS Motion.Gathrm MS Motion.Libr MS Motion.MBR and MS LowBat.GathRm MS LowBat.Util MS LowBat.MBR and Leak Detected.HVAC Leak Detected.kitch Leak Detected.util If I get a notification of an alert it becomes much easier to look at the whole home parameters involved because they sort alphabetically. eg. motion when I am not home, I can see programs activate room to room, indicating travelling intruder, on one page of MobiLinc. This makes it easy to identify false MS detections if only one triggers or they are not in physical travel order. For a leak, one remote page will show all devices. This would all be identified precisely in the original notification but there is nothing like confirming it with live real-time action. After a few years of using room based folders for programs I just recently switched to function based program folders. However, my devices are still sorted into room based folders and with the exclusive naming convention it works well at both ends of access.

Sounds great but what are you updating on a leak sensor? I would assume just links to a new PLM?

Are the files Sonos.zip and Sonos-NR.zip still intact? I only get "empty file" and illegal format" errors when attempting to decompress or view them with Win 10.

If this is equivalent to the device being in linking mode, would a query work in this manner also?

The awareness of the feature was the best part of the poll and I thank you for the information Teken. I remember some rumblings about this, some time back, but never investigated. I always figured it didn't apply to me or my devices, despite 10 MS units.