Finally got my first project actually complete.

[paulca]

You know how it is, part finished projects building up, but I finally finished one today.

Raspberry PI heating display node.

(More photos: https://imgur.com/a/mK6si )

It's quite light on electronics, just a bog standard 16x2 HD44780  LCD display, a set of jumpers and a 2.2K resistor for contrast adjust.  The screen contains a current limit resistor for the back light, it draws about 18mA.

The coolness in is the software and networking design.  Nodes in the heating system are one of a few types:

1.  The central hub (1 of)
2.  Probe nodes (many) which send temperature (or other values) to the hub.
3.  Display nodes (many) which read values from the hub and display the data, not just temps, but historical and statistical data and of course control statuses.
4.  Controller nodes (many) which like display nodes read values from the hub but then control items such as the boiler relay or potentially radiator valves and lights via Wifi or BT.

Temps and other data can be added without configuration to the hub, it will just create storage for any new data "key" it is provided.  All nodes requesting data receive all data available.

Still quite a lot of software to do.  The display currently only shows "DS - downstairs" and "OD - Outdoor" temps.  The plan is to make it display:

1.  Current Temps (possible multiple screens)
2.  MaxMin 1 hour
3.  MaxMin 24 hour
4.  Gradient (rise/fail rate last hour)
5.  Heating status
6.  Active schedule name
7.  Next schedule name and time

The displays will cycle, 3 seconds per screen and I might introduce a button or two for control, such as "OVERRIDE OFF/ON" etc.

Big thanks to this: https://learn.adafruit.com/drive-a-16x2-lcd-directly-with-a-raspberry-pi/wiring although I improvised a few things.  The contrast only needs a single resistor to GND, not a full divider, which makes final wiring easier and I put all my GPIO pins down the same side of the header cause I was feeling a bit pedantic and OCD that day.

Forgot to mention that the hub produces RRDs for each temperature.  RRD=Round Robin Database.  It's a fixed size database that once full averages down the data to a lower resolution and overwrites.  So you get, for example, 1 month of 1 minute resolution data, 12 months of 5 minute resolution data and 10 years of 1 hour resolution data.  These can then be used to generate graphs like this:



See: https://oss.oetiker.ch/rrdtool/

[capt bullshot]

Great idea,I like this kind of stuff. The enclosure looks nice, did you design it?
I'd prefer a somewhat larger graphic LCD (320x240), so one could display more values at once.

I've done similar at my home. Lots of data end up in various RRDs, mostly temperatures, power consumption, ...
It's a grown system that gets new guts from time to time: http://wunderkis.de/datenkrake/index.html
Some public data here: http://wc.wunderkis.de/webcam1.php

English titles for the diagrams:
Temperature (outdoor),
Absolute Humidity (outdoor),
Barometric Pressure,
Precipitation,
Power from Solar Panels

[paulca]

Great idea,I like this kind of stuff. The enclosure looks nice, did you design it?
I'd prefer a somewhat larger graphic LCD (320x240), so one could display more values at once.

I've done similar at my home. Lots of data end up in various RRDs, mostly temperatures, power consumption, ...
It's a grown system that gets new guts from time to time: http://wunderkis.de/datenkrake/index.html
Some public data here: http://wc.wunderkis.de/webcam1.php

Love the weather station idea.  Love applying what you know to solve a problem, because "You can.". 

I can lift 100 weather stations off a shelf, but I can bet that they aren't as configurable, controllable, tinkerable and extendable as the one you built.

Similarly my larger project is heating control and then possibly out to more home automation.  I'm convinced with the right software, sensors and control I can create a heating control system that works for me, the environment and my wallet.

For example, I have forumlae in my head for ramp times and indoor versus outdoor differentials in order to calculate pre-heat time to meet a large step up in a scheduled temperature demand.  Such as coming home from work or getting up in the morning.

Say for example it's 18*C inside, 10*C outdoors at 4pm and the next schedule is 5:45pm when I want it to be 22*C.  Based on the differential of the outdoor and indoor temperatures and a configurable constant, the pre-ramp can be calculated to reach 22*C by 5:45.  I also considered for efficiency this should ramp the temp slowly, not jump it and hope the timing is right.  If the timing is right the heating can go to 100% and just reach 22*C by 5:45, but if the pre-ramp is out it could get to 22*C half an hourearly.  By ramping the target temp linearly (for now) across the estimated ramp time it will never top out at target temp too early and waste fuel.

Then there is detecting my presence.  That 'should' be fairly easy to do with bluetooth and my mobile.  A schedule override should occur when I am present.  If I have a day off, the house should not cool through the day and ramp up at 5:45.  It should provide sensible temperatures all day.  If I come home early from work I can't complain it didn't preheat the house, but I can accept that it starts the heating immediately that I arrive.

Detecting 'where' I am is more difficult.  Am I in bed or up late watching TV?  The answer would change the heating demand.

Layered schedules seem to be the key.  A base of something like 5*C would cover 24/7 365.  If no other schedule applies it would default to that.  A weekday and weekend layer could be added to keep the place mostly 16*C+ even when I'm not in.  Basic time schedules based on when I get up and go to work or come home would set my main target temp and facilitate pre-heat/ramps.  Then a general "I'm in" override with no heating overnight, but 22*C heating all day.  The highest priority active schedule governs the control.  Inheritance in the profiles is doable and might be advantageous, but probably a head ***k to do.

The pains of heating and home automation is that the corporates are of course jumping in heavy, so proprietary, closed black box systems are prevailing.  No surprises there.  There are a few open source protocols one can implement to.  I haven't done enough research to comment much.  It matters when you want to buy a remotely operated radiator valve.  The proprietary devices will only work with "their" systems.  Honeywell, Philips, Nest and I'm sure Apple are all closed protocol incompatible frameworks.

I want open bits and white boxes so I can do what "I" want with them, not what their pesky cheap, glitzy and glitchy software provides.  I would rather have an A4 page of terminal style plain text output that's accurate and informative than 4 values in pretty colours with a nice "rounded edged boxes" bootstrap web UI with cheese easy to understand controls.  I'm an engineer god dammit!

I'll stop....

[paulca]

Case is from here: https://www.ebay.co.uk/usr/hobby_parts_and_supplies?_trksid=p2047675.l2559

Larger display is something I had toyed with, maybe for version 2.  It would be nice to have a larger display and the raspberry is more than capable of making that easy to do.  A 3" colour X display would feel like cheating though.

Displaying a 10 line labelled list of temps or other data instead of 5 pages of dual readings on a 16x2 will become appealing soon I'm sure.  That said, for heating control I need little more than temperature.

There is always a balance between tinkering and playing and buying advanced stuff off the shelf and wiring it up.  An X display takes things into a very deep rabbit hole of GUI design. 

A 16x2 display is so much less complex, but allows for some ingenious UIs to emerge if done right.  Not for the millennial generation maybe. 

I might have to get into the lower level of the 16x2 to tweak.    Bits, words and bytes, shifts, ORs and ANDs, lovely.  Then move up to bigger more abstracted displays.

[Jwillis]

That is really cool ! Congrats!

[capt bullshot]

I second you opinion regarding open / closed protocols and home automation stuff. And I don't like the stuff one can buy today, there's always at least one point (mostly many points) that does not fit my ideas of how things shall work. Today my system is doing also some control on the central heating system, not at the individual radiators but at the central boiler. This is done by simulating higher or lower outdoor temperature to the otherwise unmodified central heating controller according to some profiles and indoor temperature in selected rooms. Still looking for a good way (in my sense) to control some of the radiators. A good way IMO would be "no batteries and no wireless involved".

For a larger graphical display, there's no need to delve into GUI design. I did mine (on a Friendly ARM board, the RasPi wasn't invented then) with direct framebuffer access only, no X or other toolkits involved. If I had to build another display unit today, my choice would be either to use a microcontroller dev board with CAN bus and display (like one of the STM32 discovery kits) or a raspberry pi based one like yours with a larger display.

[paulca]

So I was working on this today, having put it off for a while.

Got a new BME280 sensor from China which highlighted an interesting development in the Arduino community.  Spite.  Adafruit do not understand how open source works.  They are petty and possessive.  They open source their hardware and software and then complain when people clone it.  They have now seem to have started embedding product codes into their versions of things and having the libraries check these chip IDs and rejecting clones.  Tut.

Still the Raspberry PI library doesn't seem to care.  The arduino finally read the sensor but only after I found code published by an ebay seller. 

Of course it might just be that Adafruit have an updated version of these chips and their libraries are checking for the latest version, but I doubt it.

Anyway I had to improvise a bit of a "Vcc and Gnd rail" in the PI as I now have an I2C bus and a dallas 1wire bus running things and both require 3v3 and gnd.  As this is an old PI 1B I only have 1 3v3 and 1 gnd.  So I soldered 3 pin headers onto the end of a female jumper lead so I can plug up to three devices/buses in now.

The net result is my sensor PI now has:
Outdoor temp - waterproof Dallas One Wire temp sensor on the end of an Ethernet cable out the window.
Indoor temp - waterproof Dallas One Wire temp sensor hanging on Dupont wires out the back of the PI
Humidity - BME280 hanging out the back of the PI
Air Pressure - " "
Aux Temp - BME280 temp sensor

I then modified my sensor_send.py to add those values.  This is where the specifics of sensors ends as this is transcribed into CSV in the format:

KEY:Value:Unit,KEY:Value:Unit,KEY:Value:Unit,KEY:Value:Unit

and sent to the "Hub" heating_hub.py node where it is converted back into a Python dictionary:

Key => ( value, units )
Key => ( value, units )
Key => ( value, units )

The lcd_heating_monitor.py process then iterates over this dictionary and displays them 2 at a time on the 16x2 display.  Simple as:

Key: value units
Key: value units

LINE_1 and LINE_2 simply toggle with each item.  If switching from LINE_2 to LINE1 also delay 3 seconds.

So the hub and display can now support any number of sensors all I need to do is add code specific to that sensor and send the CSV to the hub.

The next planned bit of work is to make the RRD datasets just as dynamic, so that any key in that dictionary will generate a new Dataset RRD if one does not exist and otherwise insert data into it every minute.

This will give me an *.rrd file for each individual key in the dictionary.  A basic cron job can be used to generate daily graphs for a week, monthly graphs for the past year and yearly graphs for as far back as data goes.  These can then be served from a very basic static Apache NG server on the Hub PI.

I may need to implement a lock though as I will have quite few threads poking around with the hub's dictionary and I don't want to read any partially written float or double values.  I could potentially already have that issue with sending data to the display node's TCP thread as it is being overwritten from the receive UDP thread in the hub.  Also potentially multiple sensor PIs writing data at the same time to the Hub.

Meh, concurrency programming is always a pain, but thankfully I can get away with a very simple RW Mutex in this case as performance is not an concern.

I haven't actually got round to controlling the heating as the boiler is technically the landlords thing and I'm not sure I want to hook up my relay to the control signal in case something independantly goes wrong with the boiler and I get the blame.

That said I think I can write the schedule and control software and just display, for now, when the PI thinks the heating should be on and I'll just monitor that.

[Inverted18650]

Congratulations on the design and 1st assembly. Cool project.

[paulca]

I also stepped up the dev environment by exporting the hub's home directory with NFS (Network File System) and mounting it on my main PC.  Then I ran the "PyCharm" IDE and pointed it to the mounted remote folder to develop directly into the remote raspberry PI's filesystem.

I also pushed the code up to GitLab to keep it safe and track changes.  Also makes it easy to deploy to new PIs just by Git cloning the repo.  Also means I can open source it later by setting the repo to public.

The code was starting to get a little bit too big to get away with Vim or Nano on the console.  Especially when it comes to things like moving generic functions into a library and importing it and replacing specific code in other files.  A good IDE like PyCharm makes this refactoring so much easier.

[paulca]

Just cross linking an update in the other related thread:
https://www.eevblog.com/forum/projects/nodemcu-esp8266-rs485-epever-solar-monitor-diy/msg2543520/#msg2543520

I could merge them, maybe.