I’ve managed to get a raspberry pi with a DHT22 sensor report its temperature to openhab via mqtt.
And just last night I was able to get a mosfet switch controlled via mqtt also on the same raspberry pi to control some 12v fans.
Obviously there’s looping scripts for collecting the temp information and for listening for mqtt events to turn on the fan.
But it seems like adding another item, ie a openhab rule to interrogate the temp and turn the fan on, as a convoluted way of controlling it - regardless of how cool it is. But the advantage of using openhab for that control is that any information like temp thresholds etc would be stored in one place, rather than on individual devices.
I kinow for sanities sake, I should actually set the raspberry pi to be self contained, ie interrogate the temp and control the fan internally, and report the temp and fan state back to openhab.
I assume I can have an mqtt binding on a switch, to receive a state, and allow the pushing of a command for a manual override?
There are two schools of thought when it comes to designing systems like this. One is to centralize all the information and logic and make the devices and sensors dumb. The other is to move as much of the smarts to the devices and only use a central controller for high level control.
So, for example, in the first approach your temp sensors would report to OH and OH would control whether the fan gets turned on or off.
In the second approach, the temp sensors would report to OH and to some code that runs on the Pi and the logic to turn on or off the fan takes placed on the device. The device will report whether the fan is on or off to OH and OH will publish to the device the temperatures at when the fan should turn on or off.
There are good arguments for each approach and neither is better or worse than the other. Some things to consider in making the choice:
do you need fail safes to keep the fan on or turn them off if OH is down, if yes the second approach might be preferable
do you have a lot of such devices that need to work together or at least interact, if yes the first approach may be preferable
do these sensors and/or fans need to interact with other parts of your system (e.g. sensor readings cause other devices to trigger, other sensors can cause the fans to turn on), if yes the first approach may be preferable
do you want to include other logic to decide when the fan should turn on (e.g. weather, time of day, whether or not you are home, etc), if yes the first approach may be preferable.
That being said, yes, you can bind a Switch to an MQTT binding and publish an override to the devices. Of course, if you go with the first approach you don’t need to publish the override to the device, just implement a check for the override in the rules.
I think I managed to do your last point late yesterday…configure the switch to push a command and receive a state (I used different mqtt topics for each direction - unsure if that’s how it should be done), and so the fan can be turned on via mqtt command, or openhab switch and the UI reflects this. So if the script that controls the fan also monitors the temp then it should to it.
In this case its a single remote device that could be self sufficient.
I’m just trying to decide if I should centralise on openhab…but I must say that in my limited python vs java/openhab programming, i prefer coding in python and find it easier to deal with than the rules system in place, also the “sensor/controller” being self sufficient makes it a little more resilient than requiring backwards and forwards communication.
Later when I, hopefully, get more control (rather than just reading sensors) then I’ll probably have to revisit once multiple devices start working together.
I usually encourage people to do what is easiest for them to do. In this case I would not recommend that and instead recommend thinking about where you are and where you want to go with your HA system and choose the approach that fits best. If it means centralizing on OH, then it is probably going to be worth the effort of learning it now. You will have to eventually.
I’ll also note that if you are on OH 1.8, you can use the JSR233 binding and write your Rules in Python. Work is underway to port JSR233 to OH 2.0 so if you wait it will be available there as well.
So I had a play tonight and came up with the following rule:
rule FanControl
when
Item boxcar_action received update
then
val Number tempThreshold = 25.0
logInfo("FanControl","Received Command for fan")
if (gf_cupboard1_temperature != Uninitialized)
{
logInfo("FanControl","Temp sensor is initialised, testing threshold: " + tempThreshold.toString())
val Number currentTemp = gf_cupboard1_temperature.state as DecimalType
logInfo("FanControl","Current temp: " + currentTemp.toString())
if (currentTemp > tempThreshold)
{
logInfo("FanControl","Fan temp " + currentTemp.toString() " + threshold " + tempThreshold.toString())
sendCommand(gf_cupboard_fan, ON)
logInfo("FanControl","Fan turned on")
}
else
{
logInfo("FanControl","Fan temp " + currentTemp.toString() " + threshold " + tempThreshold.toString())
sendCommand(gf_cupboard_fan, OFF)
logInfo("FanControl","Fan turned off")
}
}
end
But in log when I for it to trigger, (and the temp is above 25) I see it post:
2017-01-12 21:53:34.070 [INFO ] [penhab.model.script.FanControl] - Received Command for fan
2017-01-12 21:53:34.117 [INFO ] [penhab.model.script.FanControl] - Temp sensor is initialised, testing threshold: 25.0
2017-01-12 21:53:34.142 [INFO ] [penhab.model.script.FanControl] - Current temp: 25.0
2017-01-12 21:53:34.185 [INFO ] [penhab.model.script.FanControl] - Fan turned on
2017-01-12 21:53:34.216 [WARN ] [.c.i.events.EventPublisherImpl] - given new state is NULL, couldn’t post update for 'gf_cupboard_fan’
2017-01-12 21:53:34.217 [INFO ] [penhab.model.script.FanControl] - Fan turned off
OH 1.8 or 2.0? Checking gf_cupboard1_temperature to Uninitialized implies 1.8 but if you are on 2.0 it is an error
Please use Designer. It would have identified most of the errors I’m about to point out.
You need to get the state of an Item by calling .state for all comparisons and uses. So if(gf_cupboard1_temperature != Uninitialized) should be if(gf_cupboard1_temperature.state != Uninitialized). If you are on OH 2.0 replace Uninitialized with NULL.
Use the sendCommand/postUpdate method instead of the Action when ever possible. Replace sendCommand(gf_cupboard_fan, ON) with gf_cupboard_fan.sendCommand(ON).
Make sure you have gf_cupboard_fan spelled correctly, including case.
Beyond the above, the logs make no sense compared to the code. It is missing the log statements "Fan temp " + currentTemp.toString … and it shows both “turned on” and “turned off” which shouldn’t be possible.
hey thanks. I’d only really touched on designer once or twice and forgot I had it installed. Didn’t it was so powerful.
I ran it through there, and it showed why those log messages were not showing up and it was this line: logInfo("FanControl","Fan temp " + currentTemp.toString() " + threshold " + tempThreshold.toString())
Which you can see I gocurrentTemp.toString() " + threshold where threshold is a string literal.
Yeah I’m still OH1 - just waiting for 2 to go stable before I look at trying to migrate.
Start typing something and press <ctrl><space> and it will pop up a list of valid ways to complete the statement. This is very handy to discover methods available on classes.
Select the type of file you want to create (e.g. Items) in the panel on the left and press <ctrl>n to create a new file
When you do go to OH 2 you will need to download Eclipse SmartHome Designer.
Finally, OH 2 is now quite stable and I do not hesitate to recommend migrating now.
When it comes to control of these kind of systems (e.g. heating) I am a strong proponent of the “second approach”, i.e. let the device handle the closed loop control, and let openHAB monitor and control the “controller”.
My very first foray into Home Automation (several years back) started with a few wall plugs and a gateway/controller that turned out to have a cloud-based “rule engine”. With beginners enthusiams I hooked up the wall plugs to my two electric heaters in the living room, added a temperature sensor at a suitable spot in the room, and created a set of rules for a very simple thermostat.
This worked like a charm for a couple of days, and I walked around with a big smile on my face enjoying the new “stable temperature environment” I had created for myself (my house is insulated quite poorly, so the temperature used to vary a bit with the outside temperature).
On the third day, however, my smile quickly disappeard when I woke up to a VERY COLD living room (this was winter time, and I live in Norway so it can become quite cold). A warm sweater and a quick debug session later I found that my Internet connection was down, leaving my rules disconnected from the sensors and actuators - and this of course had happened at a time when the heaters were off. Needless to say I removed my wall plugs, and unregistered from the cloud service pretty quickly…
I know the situation I describe above is not directly comparable to running openHAB, but it still tells me that one should be careful about involving too many parts in the loop.
Since moving over to openHAB, I have not yet started automating my heating system - but eventually I will. When I do, however, I will make sure to have a system with “closed loop control” local to the heater, and simply let openHAB monitor and control this, instead of being part of the control loop.
To me this approach fits well with my general approach to home automation: I try to not change the fundamental way that things work, but rather add to it in some way.
For heating my current situation is several electric heaters (panel heaters, floor heating, etc.) that all have a local closed-loop control. This work OK, but by adding openHAB into the mix, and letting openHAB read a centrally placed temperature sensor in a room (where there may be more than one heater) and based on this control the setpoint, I can manage my system more easily, and I can also create a overlay of heating zones where I now only have separate heaters.
The main point, however, is that if openHAB fails for wahtever reason I am simply back to my current situation - meaning I am no worse off that today.
I think the components importance probably pays a part in determining whether to go centralised or decentralised. I mean there’s arguments for both approaches, centralised management, ie less places to back up in case of site failure…or decentralised to remove risks of single points of failure.
