shannong

It's working for me properly now. I'm not sure what happened on the first go. For sure the delay caused a bit of confusion in addition to not understanding if the luminance sensor should operate when not in night mode. I think the light sensitivity is not graduated well since I have to turn it all the way down to 30 to keep it from coming on in the day light. It also would be nice if the sensors had the ability to operate like wireless thermostat where the device sees wired power and stays on all the time rather than using a sleep mode. Thanks to all for the assistance.

Sounds like you could use the Wait. Then you wouldn't need to push the time back or guess when you might need to visit the garage. But as long as it works for you then it's fine. Enjoy.

I would suggest the addition of a Wait so that when somebody opens the door during the notification period to use the door (but not actually leaving it open) you won't get notifications. If Sensor is 'on' and Between 10pm - 630am Then Wait 60 Seconds Send Notification

I don't see a reason to use variables or dual nodes for this. I would leave it in one-node mode and put the door sensor in a scene with the desired KPL. Then write one program for the notification. If Sensor is 'on' and Between 10pm - 630am Then Send Notification Unless you have other uses for when the door is open I'd keep it simple.

As I mentioned I'm just starting to use them. I like to learn the details and functions before I begin using something new so I can better understand my options to use it. At this point it isn't working at all for me. I do use sunrise/sunset for some timers. However, there have been a few times where it's been really cloud at the end of the day and the garage and utility room are quite dim. I like the idea of controlling lights by luminance rather than TOD. However, I only want to do that if I have something to reliably provide feedback for that. I also assume another benefit would be that the sensor could switch on the light locally which would be fast and reliable vs a program which carries with it the inherent delay and occasional miss. That would save me the annoyance of thinking the sensor didn't "see" me and I start doing some sort of silly dance to create more motion to trigger it. I haven't had a chance to test and see if that's true, yet.

How does the sensitivity level scale work? Bigger numbers make it more or less sensitive?

Will the Dusk.Dawn sensor update On/Off in either Night Mode?

Thanks. That's a useful piece of info to know. I had it in my coat pocket for at least 10 min.

I have a few of the Insteon Motion Sensors and this is my first time using them. I'm having difficulty with the Dusk.Dawn node. I thought the sensor would detect night/day illuminance and that node would reflect that. However, the ISY is not getting any messages for it from the sensor and doesn't have a Current State for it. I tried putting it in my coat pocket for a few minutes and nada. I have tried both Night Modes and nothing. So I thought maybe the sensor was DOA but I tried another with the same result. I've tested with the sensitivity set to 5 and 250 and with no change in behavior. I know it's not a comm issue because the motion "Sensor" node is getting updates from it. Any guidance or extra info would helpful.

I'm assuming in your web browser you connect via the IP address of your broadband router. Certs work off of names, which is the "Issued to" field. The names are used to authenticate and validate the server you're connecting to. When you're external and connect with the public IP of your router, the web browser sees that "name" (the IP address) doesn't match the name in the certificate that is being offered by your ISY through NAT (port forwarding). So the error is normal and doesn't present a problem accept for annoyance. The traffic is still encrypted once you accept it. Even if the names matched you'd still get an error since your web browser won't recognize the "Issued by" since it was self-signed by the ISY. That would require you getting a cert from a known public CA (issuer). You could also stand up your own CA internally to create certs for your home devices. There are free packages available for Windows and Linux. It's probably not worth the effort, though.Somebody capable of conducting a man-in-the-middle attack to masquerade as your ISY would find much easier ways to infiltrate your home.

Please be more specific when you say "remotely" and "errors".

In this case the use of the word "client" means the ISY is acting as a client connecting to another TLS/SSL server. This might be a security system, for example. TLS encryption is performed using the server's certificate, not the client's. Client certs are only used for authentication. Whether or not you need to create a valid client certificate would depend on whether this other server resource is attempting to validate client certificates. If not, there's no reason for the ISY to have one and it would have no use.

It was designed to be cross-linked directly with a TH that is wired to the HVAC. The ZTH is linked to the TH and one of them is Master at any one time depending on which tstat you want to be the primary decider of when to engage the HVAC system. Changing set point on whichever is Master changes the set point on the other. For example, the TH might be the Master during the day but when you go to sleep the ZTH in your bedroom is turned to Master to control based on the local temp in there and make set point changes from your bedroom. The idea is the programming and remote control are built into the units vs programming all of that logic on an HA controller like ISY to create multi-zone control over a wireless network but still allow HA integration if desired.

Would you be using the external temp sensor capability of the ZTH in this situation? Yes and no. Actually, i would use the remote temp probe but I would modify the thermostat to use the remote probe as it's main sensor. This mod has done done and shown here on this forum. Interesting. This should work fine for you assuming the temp probe is functional. The ZTH would relay current temp and any set points to ISY. Via programs or scenes the ISY could trigger the IOLinc for the heater. The ISY could push Set Point changes back to the ZTH via programs or schedules if desired. Strictly speaking, the ZTH isn't a thermostat in this scenario since it controls nothing. It's really just a temp sensor and remote control. The ISY acts as the thermostat deciding when to turn things on/off based on current temps and even telling the ZTH what it's Set Point is sometimes. In summary, I don't see any issues with this scenario using the ZTH and ISY.

I just had a chat session with Smarthome. That tech claims to have performed a query to the ZTH from an ISY and received temp updates (ST message). Michel - Can the ISY take a closer look?

Would you be using the external temp sensor capability of the ZTH in this situation?

Is this also true for the ZTH? Yes you can change the set points of the ZTH from ISY but that's more for visual feedback since the ZTH doesn't actually control anything on it's own. Changing the set point of the ZTH will be reflected on its display but no action since it's not wired to anything. For the ZTH you'd be doing this in reverse. You would change the set point on the ZTH which would send an update to ISY where the ISY would take an action such as changing the set point of the TH which is wired to the pool equipment or controlling some other external device can is interfaced to your pool equipment. You cannot control the Fan settings of the ZTH from ISY but the ISY will see changes to the Fan state performed on locally on the ZTH.

Does that mean I cannot change the set points from the Isy? My goal is to use the thermostat to control my pool heater (with a mod using the remote temperature probe), and the point is to be able to remotely, from work for example, set the temperature set point higher so the pool is warm when I get home. I also want to create programs that will change the set point using a schedule. So can you confirm if I can set the heat set point from the isy? Because if not, my idea just died Thanks for the help. You can change the set points of the TH from ISY with schedules or programs.

Beware that If you have a gas furnace with electric igniter there is a pervasive issue with voltage spikes creating unexpected behaviors on the TH.

On the TH temp updates are always sent immediately and can be queried anytime. Same nodes for TH and ZTH. Thermostat - Main. Responder only. Modes, set points, etc. Heat Controller. Controller only when heat is active. Cool Controller. Controller only when coolInc is active. According to Michel's post above Smartlabs failed to add the capability to query the temp.

It only sends update every 15 minutes when running on batteries and every minute when running on an external power supply (purchased separately). It's also important to note that the temp is not sent every 60 seconds. It's sent every 60 second IF there's been a change. If you're on batteries, then it's the same behavior but every 15 min. If you previous change message was lost on your Insteon network then for some reason and since you can't query you won't get another update until there's another change. Currently where I'm at the day temperatures are relatively stable and close to the desired temperature in your home. Mine goes hours without sending any temp updates and I can't query it. I do not recommend this product.

I just added the ZTH to HouseLinc for testing. There are no soft buttons in HL to set the Fan mode for the ZTH. A physical button on the stat but no command. I guess they assumed anyone using it would link them together and use Master mode passing between the two rather than control the pair with a controller. So it seems the ZTH doesn't support Fan stuff. Ok. It would be preferred if ISY didn't provide me with options that aren't valid and that generate errors or silent actions.

Thanks.

L3 for the Event Viewer. Got it. In the case of the Fan issue for the ZTH, there's nothing to show in the Event Viewer since it isn't sending anything to the tstat when I run the various Fan commands via a Run (Then) with the exception of the first run of the Fan Mode command. I can send all the Fan commands fine to the TH. Both are version v.0D according to ISY and produced in mid-2013. For the ZTH and TH set point offsets, there is no restriction. It's hard to imagine any tstat being only 1 point of differential otherwise your HVAC would be constantly bouncing on/off between the two. By default, 2441's have Heat set to 60F and Cool to 80F which is a 20 point offset. I've verified both can be set to any value and put into Mode Auto. It seems the ISY is deciding to maintain a 4 degree offset between them and changing both Set Points to maintain a degree spread, which is unexpected and undesirable behavior. I don't want the ISY changing my Set Point Cool unless I tell it. Another issue with the ZTH is the current temp. It only sends CHANGES once a minute. No change means no update. I have ISY open and it's reporting the last announced temp. Fine. I close ISY Admin Console and re-open it and now the current temp is blank. Why does it not remember what it just knew a few seconds ago? And because of the other post I have you replied to you also know that I can't query the current temp. This issue is unique to the ZTH.