RulesEngine

[Pabla]

Hello all, I have a thermostat in a hallway that controls the whole upstairs floor and my room seems to get way warmer than the hallway its located in. I am not able to move the thermostat, neither are there any external temperature probes available that connect directly to the thermostat.

I had an extra Z wave temp sensor lying around so thought I'd place that in my room and use that somehow in place of the internal temp sensor in the hallway.

I can't seem to think of a good way to go about this, my original plan was to use either the AVT plugin or the Virtual Devices plugin but to my knowledge they won't work they way I intend them to. So I resorted to using Reactor, but that may become very tricky since I will need to put in a lot of fail safes to make sure the heating/cooling turns on/off when expected.

Does anyone have any ideas on how to go about this? Every time I come up with a possible solution, I always find a way that it could fail and either not turn the a/c off/on.

[toggledbits]

You're unlikely to get the thermostat to directly honor your external sensor. I would think about using the external sensor to manipulate the setpoint on the thermostat to force heating to run (or not). Also, if the differential between the hallway and the room is consistent, even across season, a "behavior" change on the part of the humans (different setpoint) may be all that's needed.

[Pabla]

I was thinking of creating a virtual thermostat which uses the external temp sensor as its own temp sensor, and then have the setpoints on the virtual thermostat manipulate the set points on the physical hallway thermostat.

For example if the room temperature is at 23 degrees, and the hallway is at 19, I would set the virtual thermostat to 20 degrees then with some Reactor trickery I could set the setpoint on the hallway thermostat to something absurdly cold so that it an trigger the a/c on (regardless of hallway ambient temp) until the room reaches the desired temp. From there then set the hallway thermostat back to either its pervious setpoint so that the a/c can turn off. I think that may be a possible solution, I can't think of any issues unless the hallway temp gets as low as the setpoint, but the temperature differential isn't that much.

[therealdb]

@pabla I think you could just use the temperature in general, if you’re using a time schedule (very common in Europe, not so common in US/Canada, from my previous trips). We usually have our thermostats set to both temperature and time windows. Maybe a simpler approach like this could also work.

A more fancy one is to watch for temperatures, make an average and lower the set point, so you’ll get a better feeling. I will not lower it too much, to avoid the feeling of being in a freezer 🥶

[Pabla]

The issue with scheduling is that with our weather here its sometimes 28 degrees then the next day it will be 9 degrees so some days a/c isn't even needed.

I think I have figured out how to go about this:

-Create a virtual thermostat
-Tie the temp reading to the room temp sensor (if that's possible)
-Set a Reactor condition to turn on cooling when the set point of the virtual thermostat is below the room temp

The only issue I am running into is creating the virtual thermostat, I created it but I cannot change the thermostat's mode. Would I need to create a custom device file type to create a functional virtual thermostat?

[therealdb]

@pabla yes, you’ll need an implementation file. I have one for heaters, but I’ve never found the motivation to do a cooler. It should be easy to do.

[toggledbits]

Well, you can use AVT for that. There are state variables in AVT when heating and cooling are called that you can react to in Reactor. And AVT will use your external temp sensor, of course.

[Pabla]

@toggledbits that was the plan but the only issue with AVT is it doesn’t work through the mobile app well.

[toggledbits]

Yeah, but it's open source, so you could take the code and just the standard device type and static JSON rather than the custom versions. I can't do that with the plugin because it would break existing users, but there's nothing stopping you from using it. No need to start from scratch.

[Pabla]

@toggledbits Okay so I took the original AVT device and changed the device type to urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1 , device file toD_HVAC_ZoneThermostat1.xml and device json to D_HVAC_ZoneThermostat1.json . The device now shows up like a regular thermostat but no longer can change its mode from off to anything else

[toggledbits]

Are you on Vera or openLuup?

[Pabla]

Vera 7.32 beta

[toggledbits]

OK. I took a dig in myself, and it still needs some additional support because so much of the "logic" is actually hard-coded in UI7.

I've put together just a prototypical modification to AVT that makes AVT itself a master device (interface only) that creates a single child device that is a dual-setpoint native thermostat type. If and only if you are not using AVT currently, you can install this hacked version and I'll help you get it running and stabilized. Do not run this version if you use AVT otherwise, as it will break all existing AVT devices.

To install:

1. Click link for "devicetype" branch of the project on Github: https://github.com/toggledbits/AutoVirtualThermostat/tree/devicetype
2. Click the green "Code" button and choose "Download ZIP"
3. Unzip the downloaded archive to a spot on your local system.
4. Open the uploader at Apps > Develop apps > Luup files
5. Drag the unzipped files (not the folder) as a group to the "Upload" button. Wait for the upload and Luup reload to complete.
6. Now, for first-time install, go to Apps > Develop apps > Create Device
7. Enter AVT Plugin or something in the "Description" field.
8. Enter (exactly--use copy/paste) in the "Upnp Device Filename" field: D_AutoVirtualThermostat1.xml
9. Hit the "Create device" button.
10. Go the Apps > Develop apps > Test Luup code (Lua) and run luup.reload()
11. There will be two reloads, one that you just initiated, and another by the plugin when it creates the child device. Wait for these to complete.
12. Hard refresh your browser. You should then see a "AVT Plugin" (or whatever you called it above) device, and a "Generic Virtual Thermostat', which is the generic-typed child.

Now, you need to configure the child device ("Generic Virtual Thermostat") with your temperature sensor. There is no UI for this version of AVT. Go into the Generic Virtual Thermostat's control panel, to Advanced > Variables and find TempSensors. Put the temperature sensor device number in there (if you have more than one you are going to use/average, put them in comma-separated). Then... reload Luup again.

The built-in (Vera UI7) web UI for the generic type dual setpoint thermostat has some bugs, but generally works well enough. The mode you are in determines which setpoints are settable (e.g. in "Auto" both, in "Heat" heat only). Setting the setpoint via the up-down controls works, but editing them by clicking on the setpoint and editing the value does not (that's a UI7 bug--it doesn't send an event when you exit the field, so the edit never takes); no workaround possible.

On the Vera Mobile app side, setting the temperature while in AUTO mode presents only one setpoint control and doesn't work, so to set the heat setpoint, go into Heat mode and set it, and to set the cooling setpoint, go into Cool mode and set it. Then go back to Auto mode if that's what you want. I'll play with that the mobile app thinks its doing and see if I can come up with a sensible workaround.

Finally, one other restriction, since I was running fast to make these changes, only one child device is supported at the moment.

[Pabla]

@toggledbits First off thanks for helping me out, this is great!

Everything went smoothly until I set the TempSensors variable. I set it to 53 which is the room temperature sensor and did multiple reloads and hard refreshes but the inside temp on the generic thermostat still shows 0 degrees.

[toggledbits]

If you look in the log, it will log what it thinks about the sensor. Look for the strings "Found 1 valid sensors" and "No valid sensors". I suspect you're getting the latter, and that's usually because your sensor hasn't updated within the "sanity" check periods (in case of dead battery). Handling that is documented in the regular README for AVT at the link given in step 1 above.

[Pabla]

@toggledbits that looks like what is happening. I guess I will wait for the sensor to update

50 06/10/21 10:39:31.102 luup_log:69: AutoVirtualThermostat: Sensor "53" ("Master Bedroom Temperature") ineligible, last battery report 1623306414 (time 23:26:54) is more than 7200 ago <0x748aa520>

01 06/10/21 10:39:31.103 luup_log:69: AutoVirtualThermostat: No valid sensors. <0x748aa520>

[Pabla]

Since this is a battery operated sensor, I can't have it update every 2 hours. Is it possible to override the 7200 second fail safe? The actual temperature in my past experience updates more often than battery dates since I think battery dates only update with a wake up.

[toggledbits]

Yes, the docs linked from the README describe this.

[Pabla]

Duh, the docs have all the info I need. Looks like everything is now up and running thanks!!!