larryllix

As per Stu's post above you have to select the scene and scroll the other way to find the controller device. It's not really a scene name but rather an initiating device name. Here is some examples. Note the different icon symbols and the name xxxx.motion.MBR which is my name for a motion sensor, not the scene name. Note the layout may be slightly different as I am using v5.0.2 beta.

IIRC the option was only at boot up time and you are right...it only suffixes values. A while back I wrote a series of programs to interrogate a thermostat and put the result in a variable. This was before v5 and there was no capabilities to do that. It takes a program, that calls one after the other in a daisychain fashion, for each value you could expect. The starting program triggered from any temp change for the stat and also has several times each day to trigger, just in case. The series ran a linear approximation until the logic switched and then you had your temperature in the variable. Of course this would all be replaced once the F/C problem gets fixed from the manufacturer.

Have a read at this. IIRC this should cover all the bases for you. http://forum.universal-devices.com/topic/17495-how-to-use-a-ms-with-lights/

Have you examined the data stream in the events log to see what the actual bitcounts look like? perhaps UDI needs to change the interface t match the ISY settings. I would write software to change the value to Celsius in ISY. If you can trigger programs on temperature reports from it you can extract the temperature reported to calculate from. This would be temporary until complaints get some action from the manufacturer about their defect. Other hardware needs to do it's own thing with the data stream values or have ISY send out your calculated results..

I have never seen a thermostat that can't display Celsius temperatures and all mine display C in the ISY admin console. Is your ISY set to use C or F?

This isn't really the limitation with ISY but rather the Insteon system itself. HA systems were based on turning lights and appliances on and off only. Analogue is really something new. ISY has provided for this expansion quite well with it's REST interface and now Node interface that are gateways to the rest of the world and could leave Insteon in the dust. IMHO Insteon is still the gold standard of non-hardwired HA though but SmartHome is just fumbling too badly for the speed of popular wants. They probably just don't understand the Chinese documents for the latest developments presented to them I have a WC8 PLC board stuffing windspeed, gust speed, inside temp. outside temp, hi and low temps for the day, a RPi stuffing every aspect of my Venstar T7900 thermostat into my ISY and use most of the parameters for logical HA responses. These are all analogue inputs. Currently ISY reports my cold cellar ventilation, HRV, and HVAC heating times each day via text message for monitoring purposes. ISY is not limited by Insteon, just our imaginations.

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.