Luteijn/Thermostat - Revision history

Luteijn at 10:44, 13 March 2018

2018-03-13T10:44:36Z

← Older revision		Revision as of 10:44, 13 March 2018
Line 186:		Line 186:
	\|-		\|-
	\|setting:<key>		\|setting:<key>
	\|value~~="value"~~		\|<value>
	\|settings for the unit, like schedule, target temperature, humidity alert levels etc.		\|settings for the unit, like schedule, target temperature, humidity alert levels etc.
	\|-		\|-

Luteijn: /* Basic idea */

2018-03-09T17:09:18Z

Basic idea

← Older revision		Revision as of 17:09, 9 March 2018
Line 20:		Line 20:

	==== Basic idea ====		==== Basic idea ====
	* Replace the thermostat by a relay/FET capable of handling the 24 V 'interface' to the Boiler. (a relay is enough for basic on-off 24V, FET probably needed if I want to talk Open Therm to it instead). Control this 'switch' with a microcontroller that can take more input into account than the Chronotherm can/does.		* Replace the thermostat by a relay/FET capable of handling the 24 V 'interface' to the Boiler. (a relay is enough for basic on-off 24V, FET probably needed if I want to talk Open Therm to it instead). Control this 'switch' with a microcontroller that can take more input into account than the Chronotherm can/does. Another option is a 24V tolerant optocoupler. I'll try that as it should take a lot less power than a relay, but still provide some isolation from the 24V. Ordered a batch of PC817's from China, thes should handle up to 50mA and 35V, which should be plenty (see under power from heater section)
	* Initially just have the Chronotherm proxied by the microcontroller via a direct wired connection, then built up from there.
	* An ESP would seem like a useful microcontroller, as it could get its input(s) wirelessly, and a nice step two would be to have one ESP control the boiler, and another connected to the Chronotherm, so it can be easily moved to whatever room I want it to monitor, and have them talk to each other, either directly or via MQTT.		* Initially just have the Chronotherm proxied by the microcontroller via a direct wired connection, then built up from there. Might just skip this step and make a wireless bridge right away.
			* An ESP would seem like a useful microcontroller, as it could get its input(s) wirelessly, and a nice step two would be to have one ESP control the boiler, and another connected to the Chronotherm, so it can be easily moved to whatever room I want it to monitor, and have them talk to each other, either directly or via MQTT. Voltage on the thermostat side seems to be available, so the ESP can use the Chronotherm for power. Would be nice to program it to be energy conservative.
	* Next, move the final decision making away from the Chronotherm, and make it just one of potentially many sensors providing suggestions. Final decision to turn on/off the Heater would be made on the microcontroller controlling the Boiler, but it might be 'strongly influenced' by a more intelligent program running on a homeserver.		* Next, move the final decision making away from the Chronotherm, and make it just one of potentially many sensors providing suggestions. Final decision to turn on/off the Heater would be made on the microcontroller controlling the Boiler, but it might be 'strongly influenced' by a more intelligent program running on a homeserver.
	* Add more mini-thermostats/sensors throughout the house that can indicate the 'need for heat' based on current temperature, Rel. Humidity, user-input (e.g. a big 'I am fscking cold, activate boiler now - RED ALERT, all engines flanking speed, ahead warp-factor 9, damn the torpedoes, go to defcon 1, dive-dive-dive, women-and-children-first'-panicbutton) and basically OR all these to decide to ('strongly suggest' the microcontroller to) switch on the heater. These would/could/should have a little 'flame' display/led/indicator to show the current boiler state too, to reassure the user(s) heat is on its way/not being generated needlessly.		* Add more mini-thermostats/sensors throughout the house that can indicate the 'need for heat' based on current temperature, Rel. Humidity, user-input (e.g. a big 'I am fscking cold, activate boiler now - RED ALERT, all engines flanking speed, ahead warp-factor 9, damn the torpedoes, go to defcon 1, dive-dive-dive, women-and-children-first'-panicbutton) and basically OR all these to decide to ('strongly suggest' the microcontroller to) switch on the heater. These would/could/should have a little 'flame' display/led/indicator to show the current boiler state too, to reassure the user(s) heat is on its way/not being generated needlessly.

Luteijn: /* Power from the heater? */

2018-03-09T17:04:50Z

Power from the heater?

← Older revision		Revision as of 17:04, 9 March 2018
Line 270:		Line 270:
	Next is to figure out what actually makes the heater switch on? If it is based on the voltage being drawn to (almost) 0, then bad luck. I suppose it is more likely what is being measured is current flowing through the thermostat, so any reasonable drop over R is enough. This kind of switch also has to work with less than perfect switches, after all. This might still mean bad luck, as it means we can't really pull much power from here, before triggering the heater...		Next is to figure out what actually makes the heater switch on? If it is based on the voltage being drawn to (almost) 0, then bad luck. I suppose it is more likely what is being measured is current flowing through the thermostat, so any reasonable drop over R is enough. This kind of switch also has to work with less than perfect switches, after all. This might still mean bad luck, as it means we can't really pull much power from here, before triggering the heater...

	Next experiment would be putting in a variable resistor and see at what value of U/I the heater is triggered, but for now it seems a bit hopeless to use this idea.		Next experiment would be putting in a variable resistor and see at what value of U/I the heater is triggered, but for now it seems a bit hopeless to use this idea. It does give us an idea of the max current a relay/FET/optocoupler would have to handle.

	==== comments welcome ====		==== comments welcome ====

Luteijn at 16:31, 7 March 2018

2018-03-07T16:31:31Z

← Older revision		Revision as of 16:31, 7 March 2018
Line 89:		Line 89:

	A rotary controller would be fun, but 3-4 buttons (next item,select,prev item,cancel) would also work as a control panel for local control/cycling through other displays.		A rotary controller would be fun, but 3-4 buttons (next item,select,prev item,cancel) would also work as a control panel for local control/cycling through other displays.

			==== faceplate ====
			draft version [[file:Faceplate.svg]]

	==== Ideas for events to generate and/or react to ====		==== Ideas for events to generate and/or react to ====

Luteijn: /* Power from the heater? */

2018-03-05T11:04:41Z

Power from the heater?

← Older revision		Revision as of 11:04, 5 March 2018
Line 262:		Line 262:
	So, 16.5V drops over 22kΩ, which means a current of (16.5/22)mA = 0.75mA flows (Ohm's law, I=U/R;R=U/I;U=RI). The same current flows through R, and 5.5V drops over R, so R is (5.5/0.75)kΩ = 7 1/3 kΩ		So, 16.5V drops over 22kΩ, which means a current of (16.5/22)mA = 0.75mA flows (Ohm's law, I=U/R;R=U/I;U=RI). The same current flows through R, and 5.5V drops over R, so R is (5.5/0.75)kΩ = 7 1/3 kΩ

	If we drop the entire 22V over R alone, the expected current would be about 3mA, so this is probably the maximum we should try to draw. ~~Need to make~~ a ~~control-measurement~~, ~~but multimeter~~ is ~~missing its fuse at~~ the ~~moment~~.		If we drop the entire 22V over R alone, the expected current would be about 3mA, so this is probably the maximum we should try to draw. I checked, and indeed when short-circuiting with a multimeter, 3mA is exactly what's on the display.
	Anyway, 3mA at 22V is only 66mW, (22mA at 3V) so not a lot of power to work with, but might be enough for a small microprocessor. 'Real' thermostats use a kind of supercap to buffer energy.		Anyway, 3mA at 22V is only 66mW, (22mA at 3V) so not a lot of power to work with, but might be enough for a small microprocessor. 'Real' thermostats use a kind of supercap to buffer energy.


	Next is to figure out what actually makes the heater switch on? If it is based on the voltage being drawn to (almost) 0, then bad luck. I suppose it is more likely what is being measured is current flowing through the thermostat, so any reasonable drop over R is enough. This kind of switch also has to work with less than perfect switches, after all. This might still mean bad luck, as it means we can't really pull much power from here, before triggering the heater...		Next is to figure out what actually makes the heater switch on? If it is based on the voltage being drawn to (almost) 0, then bad luck. I suppose it is more likely what is being measured is current flowing through the thermostat, so any reasonable drop over R is enough. This kind of switch also has to work with less than perfect switches, after all. This might still mean bad luck, as it means we can't really pull much power from here, before triggering the heater...

Luteijn: /* comments welcome */

2018-03-05T10:35:57Z

comments welcome

@@ Line 250: / Line 250: @@
 Produces:
 * Keepalives
 ==== comments welcome ====

Luteijn: /* Basic idea */

2018-03-05T07:58:38Z

Basic idea

← Older revision		Revision as of 07:58, 5 March 2018
Line 26:		Line 26:
	* Add more mini-thermostats/sensors throughout the house that can indicate the 'need for heat' based on current temperature, Rel. Humidity, user-input (e.g. a big 'I am fscking cold, activate boiler now - RED ALERT, all engines flanking speed, ahead warp-factor 9, damn the torpedoes, go to defcon 1, dive-dive-dive, women-and-children-first'-panicbutton) and basically OR all these to decide to ('strongly suggest' the microcontroller to) switch on the heater. These would/could/should have a little 'flame' display/led/indicator to show the current boiler state too, to reassure the user(s) heat is on its way/not being generated needlessly.		* Add more mini-thermostats/sensors throughout the house that can indicate the 'need for heat' based on current temperature, Rel. Humidity, user-input (e.g. a big 'I am fscking cold, activate boiler now - RED ALERT, all engines flanking speed, ahead warp-factor 9, damn the torpedoes, go to defcon 1, dive-dive-dive, women-and-children-first'-panicbutton) and basically OR all these to decide to ('strongly suggest' the microcontroller to) switch on the heater. These would/could/should have a little 'flame' display/led/indicator to show the current boiler state too, to reassure the user(s) heat is on its way/not being generated needlessly.
	* Graph the information collected by the sensors to try and find patterns to optimize the decision process and hopefully avoid user-intervention as much as possible.		* Graph the information collected by the sensors to try and find patterns to optimize the decision process and hopefully avoid user-intervention as much as possible.
			* Remote controlled radiator(knobs) don't seem needed at first, just need to make sure the thermostatic knobs are set to match the desired max temperature, and trust the system to run the heater as long as at least one room needs heat. Eventually it would make things even better to have remote controlled radiators, so a room can be kept cooler than its max even if there is another room that needs to heat up. Should be a relatively simple operation to pop off the existing knobs and replace them by remote controlled ones that can be set to the desired temperature by the system, or just opened/closed more based on the heat demand from the room they are in.
	* etc.		* etc.

Luteijn: /* = Sensor unit */

2018-03-03T17:40:28Z

= Sensor unit

← Older revision		Revision as of 17:40, 3 March 2018
Line 239:		Line 239:
	This would be running on a 'server' type of computer (not a microcontroller), and use information from different sources to come to a compound decision on turning on the heat or not.		This would be running on a 'server' type of computer (not a microcontroller), and use information from different sources to come to a compound decision on turning on the heat or not.

	===== Sensor unit ====		===== Sensor unit =====
			Basically just produces current sensor values and they occasional setting/friendly name message. Might consume settings to control its name and reporting frequency.

			===== Display unit =====
			Consumes:
			* Data produced by its associated sensor(s), which it displays.
			* Input from its associated manual input unit(s)
			* Settings to control what is associated with it etc.
			Produces:
			* Keepalives

	==== comments welcome ====		==== comments welcome ====

Luteijn: /* Ideas for events to generate and/or react to */

2018-03-03T17:40:13Z

Ideas for events to generate and/or react to

← Older revision		Revision as of 17:40, 3 March 2018
Line 147:		Line 147:
	\|		\|
	\|-		\|-
	\|K		\|keepalive
	\|		\|state="alive"\|"recovering"\|"leaving"\|"power"\|<whatever>
	\|		\|Periodic message to report (continued) presence, intention to leave, power issues (battery low etc.), and/or recovering from e.g. power outage, reset etc.
	\|-		\|-
	\|light		\|light

Luteijn: /* Control node */

2018-03-03T17:31:09Z

Control node

← Older revision		Revision as of 17:31, 3 March 2018
Line 227:		Line 227:
	* 'PA' messages ("All Hands, report to the galley"; "Doorbell"; "Incoming phonecall"; "DEFCON change")		* 'PA' messages ("All Hands, report to the galley"; "Doorbell"; "Incoming phonecall"; "DEFCON change")

	===== ~~Heater~~ node =====		===== Control node =====
	This will be located near a/the heater boiler/furnace and should be the only unit actually directly talking to it. It might include more or less 'intelligence' to make a decision based on possibly conflicting demands from different other nodes.		This will be located near a/the heater boiler/furnace (or airco, or ventilator or whatever) and should be the only unit actually directly talking to it. It might include more or less 'intelligence' to make a decision based on possibly conflicting demands from different other nodes.
	Produces:		Produces:
	* Anything a normal Room node would		* Anything a normal Room node would
Line 234:		Line 234:
	Consumes:		Consumes:
	* Anything a normal Room node would		* Anything a normal Room node would
	*		* Desires and Engages directed to it

	===== Computer node =====		===== Computer node =====
	This would be running on a 'server' type of computer (not a microcontroller), and use information from different sources to come to a compound decision on turning on the heat or not.		This would be running on a 'server' type of computer (not a microcontroller), and use information from different sources to come to a compound decision on turning on the heat or not.