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".