chago2013

Not quite... This would be the step by step process: 1. De-solder and completely remove the internal sensor, uncut, undamaged. 2. Solder in the same place the bare wire ends of the wired sensor (which has its own sensor, of course). (If we stopped here, the unit would now get its internal temperature reading from the wired sensor (this is basically what the OP did).) 3. Connect the removed, original internal sensor to the wire terminal on the inside of the back cover (where the wired sensor would normally go). What we end up with is a reversal of roles: the wired sensor would act as the internal sensor and the internal sensor would act as the wired sensor. Now, I don't know if this would work, from an electronics perspective. Which is why I'm asking if anyone thinks it would.

NP. Out of the box, the thermostat has an internal sensor, soldered to the board (see OP's pictures), which is what the unit uses to sense temperature. If you buy the wired probe, you connect it to the wire terminal on the inside of the back cover. Given that the unit reports to the ISY only the temperature of the soldered in sensor, regardless of which sensor/probe it's configured to issue *actions* from, I'm wondering if we can de-solder the internal sensor, solder the probe's wires in its place (again, see pics), and then connect the internal sensor to the wire terminal where the wired probe would normally go. Hopefully that makes sense.

So, does anyone have any input on my idea (see a previous post's edit) to swap the probe and the internal sensor, so the probe is soldered to the board, replacing the internal sensor, and the internal sensor is then connected to the wire terminals where the probe would normally go? Would this work? Thanks! Adolfo

The remote sensor works as the documentation says. At least in my case. Changing the setting in question causes the thermostat to issue Cooling/Heating/Off commands based on the temperature sensed by the remote probe instead of the internal sensor. The issues are that 1) The big temp display is always the internal sensor's, regardless of which input is used (internal or external) and, 2) The temperature being reported to the ISY is also always the internal sensor's, so writing logic based on the probe's temperature is not possible.

Very informative thread. Thanks a million to the original and subsequent posters for it. My question is if anyone has any suggestions on how to make these modifications a little less permanent. In other words, I'd like to be able to revert the mod. In the pictures I see one of the legs of the original sensor has been cut. I'd like to be able to put it back into use. I use a wireless thermostat to monitor and control the temperature inside a freezer I use to ferment home brewed beer. I've had fairly good success in implementing that, except for the fact that I have to keep the thermostat inside the freezer. This hasn't been a problem so far, but I'm concerned condensation or very low temps (38F) will damage the product. Hence the move to use a probe. EDIT: As an alternative, how about simply switching the sensors. I'd install the probe as indicated by the OP, but then install the original sensor in the terminal where the probe would normally go. Thanks in advance for any suggestions! Cheers!

Thanks!

If I understand you correctly, forecast data is available from Weatherbug. The Dashboard has the capability to use it; the ISY does not (like in programs, for example). Is this correct?

Where do they come from? I'm interested in using forecasts in my programs.

Not being familiar with the API and the firmware, I'm not sure I can answer that. The only documentation I've read is the manual, which describes how the device behaves under certain settings. What will be done, if anything, will of course be an internal decision of yours. But my vote as a consumer would be for whatever makes the device's behavior consistent with what the user manual says so customers are not confused. For example, if the manual on page 8 says, Normally, a latching switch reads the switch’s up position as on and down position as off. For example, if you turn Micro module on from the latching switch and off from another controller, the switch is still in the up (on) position; turning Micro module back on from the switch would require you to tap the switch down, then up again. The 3-way toggle mode overrides this sense feature, so in that same scenario—turning Micro module on at the switch and off from another controller, so switch is in up (on) position—you could then turn Micro module on at the switch by tapping it down. If you are installing Micro module behind a single or dual momentary switch, 3-way toggle mode is ignored. If desired, you can disable (or re-enable) 3-way toggle mode by following these instructions... etc, etc, that's the behavior I'd expect to see. If re-labeling things is required to match this, then so it is. Otherwise, there is a lot of confusion and a lot of hassle, and a lot of returned, but good, micro modules, and an overall disappointment with Insteon which cannot possibly be good for business. I hope something can be done. Regardless, thanks a million for your time and attention, particularly during these busy holidays.

I'm not sure I understand your answer. The forecasts are pulled from what UI?

As I indicated, I don't know anything about Dual vs Single Line and haven't played with the setting in the ISY. I used a brand new module to test ISY vs HouseLinc to display settings. I made changes in HL and queried from ISY to report what the latter sees. I did not try making changes in ISY and querying from HL. Switch Type HL: Latching = ON, 3 Way = OFF; ISY: Latching = OFF, Single = OFF, 3 Way = ON HL: Latching = ON, 3 Way = ON; ISY: Latching = OFF, Single = OFF, 3 Way = OFF HL: Single Momentary = ON, 3 Way = Checkbox Auto Disabled by HL; ISY: Latching = ON, Single = OFF, 3 Way = ON HL: Dual Momentary = ON, 3 Way = Checkbox Auto Disabled by HL; ISY: Latching = ON, Single = ON, 3 Way = ON Other HL: Program Lock = ON; ISY: Program Lock = ON HL: LED Brightness = OFF; ISY: No LED = ON HL: LED Brightness = 50%; ISY: No LED = OFF HL: LED on TX = ON; ISY LED on TX = ON HL: Error Blink = ON; ISY: Not Supported HL: Beep = ON; ISY: Beep = ON

The following page on the Universal Devices web site has a link to 14 screen shots of the UIs for the Admin Console and the ISY Dashboard. https://www.universal-devices.com/residential/isy994i-series/ Shots #9 and #10 show a portlet named "My Weather" that includes weather forecast information. My understanding is that the Weatherbug module only provides current information. Is my understanding incorrect? Does the forecast info come from the module or from somewhere else? Thanks!

Thanks for the detailed info. It's good to know how it works behind the scenes... pun intended... I understand my set up to be as follows: Latching NOT 3 Way I don't really understand Single vs Dual line, so I can't say anything about that. But if I had to guess, I'd say it's Single line. As I described in the original post, mine is a very simple set up. To a single, on/off switch controlling a fan's supply of electric power (again, no speed, light fixture, etc, control), I added a Micro Module to support the same thing, plus allow remote control. I'm guessing the ISY is reading these options incorrectly, or displaying them incorrectly, or the technical documentation for the MM is wrong, or there has been a firmware change that changes the way the options are read out. I can tell you there is a difference between what I get from the ISY and what I get from Houselinc for the same Micro Module. However, I believe Houselinc is correct in how it displays the settings, based on how module behavior matches the reported options. With the ISY, module behavior doesn't match the reported options, so I (and others, I assume) get confused and think there is something wrong with the module.

Thanks again, Michel. Here's the event listing. I cleared out the display before pressing the "Query" button on the dialog. Mon 12/23/2013 07:51:29 AM : [iNST-TX-I1 ] 02 62 1F D9 29 0F 1F 06 Mon 12/23/2013 07:51:29 AM : [iNST-ACK ] 02 62 1F.D9.29 0F 1F 06 06 GOF (06) Mon 12/23/2013 07:51:29 AM : [iNST-SRX ] 02 50 1F.D9.29 25.28.9A 2B 1F 04 GOF (04) Mon 12/23/2013 07:51:29 AM : [std-Direct Ack] 1F.D9.29-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Mon 12/23/2013 07:51:30 AM : [iNST-TX-I1 ] 02 62 1F D9 29 0F 1F 00 Mon 12/23/2013 07:51:30 AM : [iNST-ACK ] 02 62 1F.D9.29 0F 1F 00 06 GOF (FLAGS) Mon 12/23/2013 07:51:30 AM : [iNST-SRX ] 02 50 1F.D9.29 25.28.9A 2B 1F 30 GOF (30) Mon 12/23/2013 07:51:30 AM : [std-Direct Ack] 1F.D9.29-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Thanks for the response, Michel. The potential mislabeling I'm referring to would be a little more than what you said. I'm talking about the possibility that what is being displayed as "Act as 3Way" may actually be the setting for "Latching".

I should add that with the configuration indicated above, the behavior is as indicated in the first paragraph of the section titled "3-Way Toggle Mode (Latching Switches Only, Default)" on page 8 of the MM manual. This is incorrect, as with the "Act as 3Way" option checked, as I have it, it should behave as described in the second paragraph.

I have two ON/OFF Micro Modules (MMs), each controlling a fan in a different location of the house. Each is connected to a single toggle switch that is just an ON/OFF. There are no other connections or complications (no 3-way, etc). The MMs work as advertised, all behavior is as expected, status reports update correctly in the ISY, there are no delays or apparent communications issues, et al. However, getting the MMs properly configured with the ISY was a challenge and I'm wondering if some of the Device Options in the pop-up window are mislabeled. Referring to the image I attached to this post, please correct me if I'm wrong, but in a scenario like mine, shouldn't the only checked checkbox be "Latching", with the other two ("Single Line", "Act as 3Way") remaining unchecked? In my case, the only way I could get both MMs working was by checking "Act as 3Way" and leaving the other two unchecked. Is this a bug or mislabeling? Or is my understanding incorrect? Thanks!

Thanks for the confirmation. Why would the query change a device's status?

I've seen it happen on more than one occasion and with different devices, like an ApplianceLinc. A program did trigger based on the 100% status report. I have a folder that contains programs that trigger when another program runs, for notification purposes while I'm still writing programs and working out the kinks. The notifier for the xmas tree on ran at 3:00:26 AM. It could be a comms issue, particularly if the controlled load is on and causing noise. But the tree lights were off. So, is the Query All program just to sync up the controller with the current status of the devices?

I've had my ISY-994i (standard; firmware v4.0.5; UI v4.0.11) now for a few weeks and have it working well, except for this weird behavior I see when the out-of-the box Query All program runs at 3:00 AM. When the program runs, it seems on occasion some device that I know for a fact was off when I went to bed reports a status of 100%. For example, last night we turned off our xmas tree. We did it manually through a KPL switch, plus the "Sleep Time" scene I trigger from a RemoteLinc2 next to my bed includes turning it off. The tree is connected to an Outletlinc I purchased a few weeks ago as well, so I assume it's of a fairly recent firmware version (the outlet, not the tree ). I've seen the same behavior with other devices, but I blamed user error in my programming or some other more practical reason. It seems to happen randomly and, of course, since I'm not up to see it, I can't confirm whether or not the device is actually on (I guess I can change the schedule to run during the day). What is this Query All program and why does it have to run? Why would an otherwise OFF device report ON/100% status completely on its own and possibly even actually turn ON without being commanded to do so and from an OFF status starting point? Is it OK to disable the Query All program? Or is it a necessary part of the functioning of the controller and system overall? No other scheduled programs run at that time. I do have a wireless thermostat that may or may not, depending on temp, turn on a couple of space heaters in our bedroom at the same time the Query All program runs. But that doesn't seem to have happened last night. And I have pretty good network communication. Most of my devices (17) are Dual Band and I have two Access Points/Repeaters. Response is fast for all scenes and programs. I'd appreciate a little light on this subject as I'm totally baffled by this. Thanks!