Introduction

I have always had an interest in energy efficiency and its conservation. Way back in the 1980s we had one of the very early domestic condensing boilers, a glass fronted, wall mounted Trisave. Although many considered them unreliable and temperamental ours was still working in 2007 when we sold the property. (Some may consider that to be a lot more reliable than more modern variants!)

With the approach of winter I was looking at home weather stations and ways of logging data in order to see if the winds here affect my gas consumption and comfort levels in any obvious way. These searches lead me to the Rfxtrx433 module and, through its use under linux, to home automation.

So, is there a way to better control my home heating system without installing lots of new wiring and newer versions of bits I already have?

The answer seems to be that it's not very easy - at least using widely available components here in the UK. Domestic heating control seems to have changed little over the years, generally based on wired sensors and fairly basic programmers in the majority of properties. More advanced controls are available but often sold as part of a system, installed by specialists.

In terms of adding DIY control to an existing heating system, I found that there is not very much information out there - if you can find any at all. Very little of what is available is written in English.

Useful bits I did find:

• Heimautomatisierung-mit-fhem.pdf by Ulrich Maaß (with a section by Martin Pittner) is the piece I found most useful as an introduction to wireless control and fhem, and would recommend it to anyone interested in trying fhem. It is a long document, written in German, (google translate may help with that if you are careful with the results, google translate produces reasonable results for many texts but technical terms and documents can sometimes take some deciphering).
• Conrad Electronics the UK site of a European company that sells a variety of home automation products.
• Fhem a server for house automation that works with products from a number of different manufacturers. Other software is available but fhem appealed to me the most. See also domotiga, Freedomotic, Minerva, MisterHouse, Pytomation.
• MMaplin have a small home automation range, as do some of the DIY sheds.
• Automated Home which has a useful forum.
• LightwaveRF is a manufacturer's site with its own forum.
• UK Automation a retailer of home automation products.
• Interesting page by Damon Hart-Davis with further useful links.
• More links below

My Progress

I am updating various parts of this document as I learn more so I apologise if it seems rather disjointed

October 2013
November 2013
December 2013
January 2014
February 2014
March 2014
April 2014
May 2014
June 2014
July 2014
August 2014
September 2014
October 2014
November 2014
December 2014
January 2015
February 2015
April 2015
June 2015
July 2015
August 2015
October 2015
November 2015
December 2015
March 2016
June 2016
August 2016
September 2016
January 2017

October 2013

Initial aims

At this stage I am not looking at automated or remote controlled lighting. My house is small and all lights are CFL. I have read that some, perhaps even most available switch modules don't like CFLs. Also, it seems that most modules require a neutral feed within the switch box. This is rare in older UK installations and absent in mine (although I understand it is now recommended practice by some).

Although I hope to improve the controllability of my current heating system, I believe there is little scope for energy saving, I am already classed as a low user.

fhem

fhem is a server for house automation. Ideal for automating common tasks in the home such as switching lights and heating etc. as well as logging events including temperature and humidity, even weather station data.

fhem is written Perl.
Now, I have always found Perl rather scary, all those lines of unintelligible characters! (Many years ago I purchased O'Reilly's 'Perl in a Nutshell' with a view to learning something of it.
I bought the wrong book!
It is an excellent reference guide but not an introductory text. O'Reilly do have more suitable titles, other publishers too. A good web based introduction is Beginner's Introduction to Perl.)

Radiator valves

I have TRVs on all but two of my radiators. They are labelled Randgyr (Danfoss Randall?) and stamped LG on the body (Landis & Gyr?), and so old that they don't even get a mention in web searches! They are all still working with no apparent stickiness. I will wait for the new heads to arrive and see if any of the supplied adaptors fit them before going further.

Most/all the new wireless heads are claimed to fit most existing/current valve bodies, they have an M30x1.5 'standard' thread . Many heads have a few adaptors included. Suppliers and manufacturers of conventional TRVs in the UK don't seem to list this particular aspect in their specifications.

My final decision

After a lot of reading and translating of documents I have ordered a Raspberry Pi Model B with an RTC module from CJE Micros. I had been considering getting another PCengines Alix to run fhem but that would be a more expensive option (I already have one Alix running m0n0wall SmallWall and another debian squeeze as a small server). Many other users of fhem are using a Raspberry Pi so I expect to be searching for more information as I put this all together.

The following are on order from Conrad Electronics:

• eQ-3 MAX! Wireless Radiator Thermostats.
• eQ-3 MAX! Wireless Window Sensor.
• eQ-3 MAX! Cube LAN Gateway LAN.
• eQ-3 MAX! Eco Switch.
• HomeMatic Wireless dual switching actuator.

Documentation for all of these is available from http://www.conrad-electronic.co.uk/, http://www.elv.de/ or http://www.eq-3.de/. There is generally an English translation provided.

The Raspberry Pi arrived the day after ordering, I knew it was going to be small - but it is very small! This is a 'Made in China' version.

I thought I had every type of USB lead ever made, but not so - it requires a μUSB plug for power, now sorted from a pound shop, along with a 4 port hub to hack into a powered hub for the various always-on USB powered devices that I seem to be collecting. (Of course I later found a μUSB lead hiding in a drawer.)

Installing raspbian went smoothly, I'm only doing a minimal install, with no GUI. Same with installing the fhem .deb package, it reports some missing packages at first, but soon sorted after running aptitude.

Once fhem is installed and running, the web GUI is available at http://<ip>:8083 . There is little to see with no devices attached but it is all working. I was confused at first as the Save button that appears in so many fhem screenshots is missing! This has been replaced with the Save config button to the left hand side in recent versions. Commands can be entered in the top bar followed by <Enter> - remembering to Save config to make any changes permanent.

Whilst waiting for my Conrad order I have reinstalled raspbian to an 80Gb USB hard drive booting from an old 128Mb SD card to improve long term reliability. All very easy and well documented on the raspbian site.

The image below is of the fhem web interface showing systats

sysstat readings and load plot

and RpiUtils data for the Raspberry Pi

RpiUtils readings and cpu temperature plot

It's now one week since my Conrad order was placed and I have received just the switch with the rest to arrive in 'approx. one week' according to the invoice. No other paperwork.

Another week gone by and I should receive the rest of my order tomorrow according to a UPS mail update. A bit more communication from Conrad would have been nice. I can't even see my order on my account pages on their site!

The rest of my order arrived yesterday - and I am exhausted!

I have spent hours and hours fighting to get the Cube firmware updated.
In its default state it would not connect with fhem on port 69210 but did manage some output once accessed on port 80.
According to fhem commandref this means it has an old firmware version installed, so off to the eQ-3 website to download and install the MAX!_Setup software on my XP machine.

Once installed all I could get was a series of repeated no connections. I tried all the suggestions from the various FAQs and web searches, uninstalled Java, uninstalled and reinstalled the MAX! software, ran CCleaner on the registry, tried direct from PC to Cube, set up a small network using private addresses instead of my public block, tried a port mapper, everything I could think of that might have some effect.

Finally I got out my old and slow laptop, also running XP, and installed the MAX! Software. It offered to update the Cube firmware with no other dialogue whatsoever.
The other XP machine will now connect too - but I have to set IP addresses every time. Not a very impressive piece of software!

I have no idea what the problems may have been so cannot offer any advice other than try another machine before giving up.

The internet LED on the Cube continues to flash. This is expected and indicates no link to the online portal - to which I've not subscribed.

Next I have to sort my radiator valves. None of the adaptors will fit my existing valves so I will change them all - and fit a drain cock for next time!

Incidentally, batteries are included with all eQ-3 devices that require them.

That's all done.
I chose Salus TRVs, not for any particular reason except they were available and on one of the compatibility lists. The eQ-3 heads fit but do depress the pin very slightly once screwed on (I may look around for some shims to allow the valves to open fully).

All but one of the heads now attached along with the Eco Switch. Teaching each one to fhem went well and configurations were written automatically to fhem.cfg. The window sensor is now fitted too, has to be associated with the bathroom valve head. Each head has to be set to Manual, the temperature adjusted, then set back to Auto in order to start sending temperature data to fhem. fhem.cfg can be edited in accordance with the MAX! wiki to generate plots for each valve.

All sensors have the

attribute set in order to disable logging every 10 seconds - the heads report temperature only when the valveposition or desiredTemperature is changed. The window sensor supplies only 'Open' or 'Closed' status, the Eco Switch nothing at all - it works solely through the Cube (this is rather a shame as it might have been useful to issue a warning when leaving the house if windows are open). The Eco Switch doesn't even appear in the Windows MAX! software main window once configured although there is a section to configure button actions.

I have set daily temperatures for each valve using the MAX! software in two hours sections initially (the maximum is thirteen changes per day for each day of the week). There are reports that the fhem weekProfile command produces errors as the format hasn't been fully decoded so far (this appears to be related to firmware version and some fixes have been applied as I write this). The MAX! software seems safer at this stage.

Radiator valve plot

I have read reports that the valves are noisy. I don't find them particularly so during general daily life. It is more noticeable in the quiet of the night in a bedroom but not nearly enough to wake me. The actuator itself is mechanical so some noise is to be expected

The HomeMatic switch does not talk to the Cube so I have to get something else for that in order to control pump and boiler, probably a HM-CFG-USB. The HM-CFG-LAN and CUL are more expensive - and the HM-CFG-LAN seems in short supply at the moment and it is a lot bigger than the USB stick.

Findings to date

I am very impressed so far, even though I have yet to control the boiler/pump automatically.

I have been working on getting things ready for this and spent some time customising the Seasons (Jahreszeiten) subroutine from a forum post which controls heat input based on current valve positions on a month by month basis.
Further reading has caused me to abandon this idea. The eQ-3 heads are not simple actuators. They use PID in their actions and base valve settings on the time taken to reach desiredTemperature amongst other things - the valve will close only sufficient to try to maintain the desiredTemperature (this would suggest that a constant flow might be better controlled than intermittent). There is more information about this in some of the ELV forum posts.
I may still use valve position as a basis for switching but at a much lower level, perhaps 5 or 10 to start with. (I may change the central heating pump at some time to an auto-adjusting type.)

Setting room temperatures in degrees seems more difficult to get right than just tweaking a standard TRV. I have found it easier to set a colder temperature at first then adjust upwards.

As far as I am aware the basic/standard form of these valves can only be programmed through software such as fhem, the MAX! Wall Thermostat or the MAX! software - or other similar but I haven't tried. (There are other valves in the MAX! range that do allow setting from the valve head.)

The valves are normally run in Auto mode. Altering desiredTemperature is done either through software (eg. fhem or MAX!) or from the dial on the valve head (in Auto mode).

If the attribute

is set in fhem, the valve will revert to its programmed settings as it enters the next programmed time phase. (setting using the until feature also reverts to programme once finished, even across time settings.)
This feature affects the way each valve needs to be programmed.

A bedroom may require different setback temperatures for periods during the day and night but higher temperatures for when you go to bed and get up in the morning.
Should you get up early one day, desiredTemperature can be lowered as described above. If a single time slot is used for these short periods, it will revert to the programmed settings at the end of the slot.

A room used at irregular times may require something completely different, perhaps a more comfortable setback temperature for most of the day.
When in use room temperature can be raised either by using the programmed Boost function or by raising desiredTemperature. If the latter, it may be better to set multiple time slots through the day so the valve will revert to the programmed settings at the end of any slot during which it has been altered without any further intervention.

I have a HomeMatic HM-CFG-USB adaptor on its way from Germany. This is to control the HomeMatic switch that is going to be used to control my pump hopefully. The software is already complied and ready on the Raspberry Pi.

The HM-CFG-USB has arrived and was recognised immediately on plugging in. The switch has been wired up, using one channel for the pump, the other for the boiler.

I was a bit surprised after pairing to see

devices appear in fhem.cfg. I eventually found the reason for this in the fhem commandref.

November 2013

I have added further refinements to my configuration to control the switches and all seems to be working well. If the total of all valvepositions is greater than 30, turn the pump and boiler on, less than 30, turn both off. I have also added a small delay between switching pump on, boiler on and boiler off, then pump off.

Switch actions plot

Installing the last valve head produced a number of errors in the log. It took me some time to work out that this seemed to be caused by the Cube being right next to the head, perhaps the signal was too strong. Moving the Cube a few feet away seems to have sorted things.

It's all been working well for a week or so now but a pinhole has appeared in my bedroom radiator so that will be changed next week. I wonder if the other radiators will follow, it often happens that way.

Radiator now changed and all set up again. A warm bedroom again!
I have chosen a slightly higher output than the old one, seems to make sense as its operation and temperature will be fully controlled and may allow a more rapid warm up.
I have altered the pipework so that the flow enters a top tapping on the radiator - the traditional connection method!
I can now read and alter the valve without bending down.

I have found a shim for the heads so the valve will open further, a standard ¾" fibre washer, split to allow it to expand enough to fit over the valve nut.

I have ordered a few more Perl books at a couple of pounds each from ebay - that has to be good value!

I have acquired two sets of remote power sockets. Three UK 3 pin sockets and a remote in each pack - the remotes are specific to each model (ie. HE830S or HE330S) so are not interchangeable.
They are HomeEasy/Byron HE830S and HE330S. I think the S may be for the silver finish as they also do white with a W. (These were 'end of line' in one of the sheds (large DIY stores) so I had no choice of colour.)
The HE830S will survive a power off once taught to the remote.
The HE330H are reset by removing power for over 55 seconds, learn mode is set on power on.

I had trouble with these in fhem with a RFXTRX433. Lots of disconnects, USB device disappearing then reappearing on every action with nothing at all useful in the logs.
I spent quite a few hours on this.
I finally installed fhem on one of my desktop machines, all sockets working with no problems at all.
I concluded that there may be some USB issues on the Raspberry Pi - a known issue.
Trying again later today all is now working on the Raspberry Pi including proper, useful logs!
The only differences between yesterday's attempts and today's on the RPi are that I now have fw-68 rather than 69 on the RFXTRX433 and I ran rpi-update this morning which may have installed revised firmware on the RPi.
Of course it may just have been a faulty upgrade to fw-69 but everything worked well with it in RFXmngr.

I have acquired another cheap set of HE830S.
Only two out of the three devices would work with both fhem and RFXmngr.
After many tries at unplugging and resetting, the non-working switch all is now OK. The rest are all still working.
Something odd about the initial setup with some, but not all, of these switches.

I came home the other day and noticed that my pump and boiler hadn't switched off as expected after I had set the Eco Switch.
I looked at the logged events and it seems the change and hadn't been caught by the notify - now modified.
The Eco Switch sets all valves to manual in Eco mode. Hopefully I'll catch it next time.

I have been looking again at the HE330S modules and have changed my opinion on them.
I had thought they would be of little use if they require re-teaching every time they are plugged in.
Initially I only tried one of the three to determine that it worked but I noticed that when re-powered it still responded to fhem commands on the original settings.

I have now taught all three to the remote and integrated into fhem. So far they all respond as would be expected to fhem despite being disconnected from the power for long periods - a week so far and still responding.

I have now got a weather station, a HomeMatic HM-WDS100-OC6-0. This provides the following readings..

Weather station readings

The multiple rain, temperature and windspeed readings are created by the fhem average module, Dewpoint by the dewpoint module. I'm not sure how accurate the station readings are, no doubt I'll find out over time.

Brightness is read by a photo-diode and registers 9 in the dark at night - the plotting has been adjusted accordingly. Sunshine duration is incremented once brightness rises above a certain threshold. As yet I have no idea what this threshold might be, or the meaning of the sunshine units - which increased by 0 yesterday,13 today.

Rainfall uses a tipping bucket mechanism and is an incremental counter. To create daily values requires subtracting the previous day's reading. The manual gives instruction on how to calibrate.

The plots look nice however..

Weather plots

Weather plot for the last seven days

The station sends data very two to three minutes, this generates large logs.

creating the plots seems to take longer and longer as the logged data increases. I have changed settings so that fhem only logs the combined lines. (Since changed to separate logs for full and short data as well as another for values generated by the average module).

December 2013

The monitor on my main machine has just died so now using the one from my backup. As I do web updates from that computer I won't be able to upload again until I get a replacement.

All is going smoothly with fhem, both heating control and weather reporting. I keep tinkering with the code but only altering the appearance of the web interface, nothing major.

I often search for and read various posts and forums related to home automation and I am happy that I chose to go with fhem and this hardware, other systems and hardware seem to be more expensive and more limited in their options.
Of course, I'm sure there are others who have made different choices and are just as happy.

I have purchased a few more HomeEasy devices from UKAutomation, wall switch, internal and external PIRs. All are recognised and working with fhem and RFXTRX.
The switches are easy to set up but the PIRs are more fiddly with on-time, distance and light level sensitivity, the external version particularly so as they have a potentiometer for distance setting. I think it will be a few more days before I am happy with them.

I came across a small issue yesterday whilst trying to set up a small under cupboard type 8W fluorescent strip lamp in the kitchen - so I don't have to turn the main light on when making a cup of tea. I plugged this into an HE330S adaptor.
It would switch on reliably but not switch off. Changing to one of the HE830S adaptors seems to have sorted things. I guess this relates to the resistive/inductive load of the lamp.

I have set up a number of timed sockets for when I leave the house as well as a series of cascading lights with on and off delays triggered by one of the PIRs. This is all set from one of the switches, on for away, off for at home and it is working perfectly - so far.

New monitor is now installed and calibrated so I should be able to update as soon as I get the other machine set up again.

I came home the other day to find I couldn't access fhem via web or the RPi via ssh.
I powered off then on again, all came back up.
Earlier in the day I had swapped out an old MSI BToes USB bluetooth adaptor for a new small Dynamode one as the BToes often failed to respond to the presence of my mobile. I am pretty sure this change was the cause of the lockout but can find no evidence of what was hogging resources on the RPi in any of the logs.

Another issue a few days later!
I set up a readingsgroup for battery status and another for MAX devices. Overnight the switches controlling boiler and pump got stuck in an unknown state - so no heat first thing in the morning. There were a lot of timeout messages from the MAX Cube this morning. I usually see a few but these were much more frequent.
The cause of these may have been that all MAX devices were being queried, since restricting to just the radiator valves the logs look better.
I have no idea if or how it may have affected the HomeMatic switch in some way.

I read and log my gas and electric meters weekly and this morning noticed that gas usage week by week in November was higher than last year, December, so far, less than last year.
Perhaps no real change in my usage overall - as I expected.
Weather and outside temperature are obviously factors but the comfort level indoors is certainly better now.

Frustrating Max! Cube issues! I had a very brief power outage here that took down all my networking hardware. It was only very brief from looking at the logs, possibly related to the high winds we have had here affecting overhead power lines. Everything came back up as it normally does but I was seeing entries like this in the Cube logs..

Has the Cube reverted to CET rather than GMT? Perhaps it has lost its DST (winter/summer) setting?

I tried setting the clock from fhem with no luck. (I have since read that altering the 00_MAXLAN.pm module may have worked but that seems an odd way to do things and I doubt would have restored to what I had working before - and may require modifying new versions as well perhaps).

The system was still working, but of course the Cube had sent its time setting to all the valves, so programmed changes were happening an hour earlier than they should.

I switched on my backup machine and booted the XP Pro install.
Max!_Setup appeared to connect but would not send timezone or winter/summer settings, it just sat there with a spinning icon, waiting for some response - me too! I could change temperature settings on the individual valves with no problems at all.
It was getting late by this time so I gave up for the night - without looking again at fhem.

In the morning, my heating was off and all radiators cold. fhem had lost all contact with the Cube and nothing I did brought it back. I could have tried resetting the Cube but from past experience this removes the installed firmware and all programmed settings and it is likely I'd have all the frustration of my initial Cube setup.

I guess that all the valves were doing their programmed thing but there is no way of telling without the Cube relaying signals to/from fhem. As the boiler and pump switches are set depending on valve positions, no data means no switching.

Time to get the old laptop out (XP Pro). Max!_Setup sends time and winter/summer settings with no issues whatsoever! Communication with fhem is restored, everything is working again and back to normal.

What a frustrating piece of software!

I should add that for the couple of months between the initial setup and this issue, the MAX! system has worked faultlessly.

I came across an interesting, though quite old, series of blog posts in English here, I guess using an earlier firmware version. Perhaps I will try to set the Cube to DHCP next time I have to get the laptop out, though quite possibly I may have tried that before. I certainly did from the XP desktop machine without any success.I already run a DHCP server on m0n0wall and there is a reservation set for the Cube.

If time is set via NTP does it adjust for locale or will it revert to CET again?

The Cube install literature does state that its address should be assigned by DHCP, or use the default 192.168.0.222. That is certainly not the only issue as should have been the case when I tried with a network set up using private addresses.

A short time later I lost contact with fhem via web or the RPi via ssh again.
I was about to go out, so power off reboot, a quick check that all was working and leave. I would check the logs on my return.

Arriving home I looked at the fhem web interface, all seemed OK, but I then noticed I had no mail or usenet via the RPi - no ssh access either. Another power off reboot. Before I had a chance to log into the RPi to check logs, I received a logcheck mail full of lines like this..

A little searching found this
Super Mini Bluetooth 2.0 Dongle. The device is recognised and after installing bluez-firmware you can bring it up with hcitool hci0 up. However whenever you try to pair with any device it will cause kernel panic and lock up the system. Confirmed on Raspbian, RaspBMC. The device is a counterfeit Cambridge Silicon Radio device, probably with several bugs in it causing lockups.

I can't post lsusb results as it's now disconnected and in the bin but it did report as a Cambridge Silicon Radio device - and no lockouts since.

January 2014

I have all but given up trying to use the HomeEasy HE861 external PIRs. They work OK indoors. I have one fixed outside, about 10m away from the RFXTRX, and the signals are only very rarely registered.
The walls here are not particularly thick so I don't think that is the issue, the transmitted signals may not be powerful enough.
The antenna must be on the PCB, and not easily identifiable, to me at least, otherwise I'd try adding a small wire whip.

More winds and another power outage - the Cube has a 60 minute time difference again! The laptop will not connect to the Cube using DHCP - even with the fhem connection disabled:

Going back to my previously entered network settings, connection is almost immediate.
Timezone setting is blank again.
I set it to Europe/London (GMT) and disconnect from Max!_Setup.
Setting the time from fhem now sets the correct time with zero time difference.

Net searches seem to indicate that the Cube gets its time from 85.25.143.185, an eq-3 server, presumably set to CET time and there doesn't seem to be any way to set the timezone other than from the Max!_Setup software.

It seems that although the Cube time is now correct, the valves are still set to CET so an hour out.
Last time I corrected the time with Max!_Setup I also resent the weekly temperature settings to each valve.
I could try that from fhem but will leave it for a while and see if it all settles down.
I suppose I could also try disconnecting the Cube to see if reconnecting sets the valve times correctly (previous deliberate disconnections have not caused the Cube to revert to CET).

I have just received an order of 1-wire bits from Sheepwalk Electronics, I have come across references to 1-wire over the years and been intrigued by it but not gone any further. There is some information available, scattered over various sites, and plenty of datasheets. I have not yet found a single resource for the hobbyist.

Some may consider 1-wire rather simple and hardly worth the effort of running cables to each device, however it is ideal for long term monitoring, even as far as building in during construction, perhaps to monitor seasonal condensation risks.
If I ever get around to redecorating/renovating here I may include a number of suitable devices. I will be using a couple of the DS18S20s to measure heating flow and return temperatures.

I now have an RPi3 host adaptor, ready assembled, SWE2 sensor connection module and SWE3 humidity sensor module, both in kit form plus a few DS18S20s.
There are no instructions with these kits but the pcb silkscreens show component placings and are easy to follow and there are completed images on the relevant pages too.
I have done a great deal of soldering in the past, but nothing as small as the DS2438Z.
Possibly the last time I soldered a new IC was building a Sinclair Scientific calculator - and that may have used a socketed chip.
(I must remember to disconnect the smoke alarm temporarily before I start assembly to save the cat from having a heart attack!)

All now assembled and they look quite reasonable, will soon see if they work too!

I have also ordered another Raspberry Pi from ModMyPi hopefully arriving in the next few days.
I will test the 1-wire kit out on the new RPi initially, to ensure all is working as well as setting up the RPi3 RTC to work with nntp - I'm not sure that the configuration is the same as for the RTC I have on the existing system.

Something has reset the Cube time, it's 60 minutes out again.
This time I have altered the MAX pm file and restarted fhem, it has been running overnight since then but disappointingly it is still showing 60 minutes difference. I'm not sure what time the valves are using yet, I will check them later on.

The new Raspberry Pi arrived, I installed Raspbian and a few other bits including owserver and i2c-tools and added the Sheepwalk Electronics RPi3.
All tested out OK, added the two 1-wire modules I assembled and they are both working - so my soldering skills aren't too rusty.
The RPi3 RTC uses the same chipset as my existing RTC so no changes needed there.
Time to swap over.
I have also got a new Multi-Pi Stackable case as the RPi3 won't fit in the case I have but will need to find some new spacers to make use of the top section of the new case.

After booting my main RPi, /etc/owfs.conf has to be altered to remove the default FAKE devices and add the location of the real devices. owserver then has to be restarted. Once the server is defined in fhem the various devices can be configured.
I am still a bit confused by all of this. It seems that devices can be configured in a number of ways and as yet I have no idea of the differences. By default the humidity sensor appeared as an OWDevice but I have deleted this and set it as an OWMULTI - simply because it seems easier to configure and show humidity value this way.

Temperature and humidity plot with the Sheepwalk Electronics SWE3 module -
I had moved the sensor from the hall into the bathroom just before I took a shower

I have tried adding a bare DS18S20 sensor and that is working and I've found some reasonable looking 1.8m CAT5 leads for 1-wire devices at £1 each in a local pound shop.

Time to make up some temperature sensor leads but I'm confused as to the best way of doing this.
Most sources suggest using a 4k7Ώ pull-up resistor however Sheepwalk seem to be using 1N5817 Schottky diodes on their current SWE1 modules.
I have tried searching online regarding this with very little success although DS1820+1N5817 does produce some inconclusive, results.

I suppose it matters little as long as the sensor is accessible, it can always be modified later, a sensor built within a structure for long-term monitoring is a different matter,
There must be many of these devices installed using a resistor, as per the original data sheets, so perhaps that is the best course to follow.
The data sheets do mention using a Schottky diode to terminate the bus in some circumstances but not for every device as far as I can see.

After installing the 1-wire interface to my original RPi and fhem, the Cube is still reporting 60 minutes difference but valves are now synced to GMT. No idea what it all means but I'm happy to leave as is.

I could not make up my mind whether to use a resistor or diode to make up sensor leads so made up two with just the DS18S20 sensors attached and will alter them as I find out more. I attached these to the flow and return pipework of the boiler and the result of one day of readings is..

Flow and return temperature plots.
For the first few hours the valves are running on a night setting, then day setting until just before midday when set to Eco until 8pm.

I really don't need readings to 3dp. An integer plot tidies the y-axis labels but changes the graph very little.

I came across advice somewhere online suggesting that it is not necessary to add additional components to the sensors unless there are problems, if there are problems then you should add a Schottky diode to the last device on the bus.

I now need to think about how I can use this information to control the boiler in the most effective manner.

The Cube is still reporting 60 minutes time difference but the valves are operating at the times I wish them to. So I'm still happy.

I have been having issues with the HomeEasy wall switch and my 8W fluorescent kitchen light. It works sometimes but many times it just won't or it will switch on but not off, or the other way around. fhem seems to receive and transmit the signals and everything is logged as expected. I will replace the fluorescent with a standard incandescent lamp for a week or so and see if that is any better.

I have just come across an article on the BBC website, How smartphones can cut heating bills by a quarter, (no idea how long that link will remain).
It compares the installation cost of a few systems and potential savings - probably based on manufacturer's figures.
Perhaps heating control beyond simple timers and programmers is finally being taken seriously in the UK.

There are also reports today of a fridge that has been discovered sending out spam after a web attack managed to compromise one of the 'Internet of Things' :)

I have a concern that with so many new systems appearing, some may not be around for long given marketing forces, competition etc.
Most systems are based on a manufacturer's own proprietary protocols so no communication is possible with other manufacturer's devices. If a bit of kit fails and no replacement is available, the whole system may become useless.

I have had another freeze of the RPi and been unable to connect to it again. It had been up for a few weeks with no sign that anything was wrong. As occurred in previous freezes, the HD LED was flickering indicating that there was quite a lot of disk activity.
The only way out seems to be to power down the RPi and HD. Everything came back up, nothing at all in the logs after the freeze occurred and nothing to indicate what may have caused it, fsck shows no issues.

There are many reports of much longer uptimes than mine so it has to be something unique to my setup. I don't believe it is anything to do with fhem, more likely a USB problem or perhaps something to do with my Chinese manufactured RPi.
I can't see an easy way of finding out exactly what, with no logs as a hint - other than swapping bits of hardware out one at a time.

I have had this HD enclosure for a long time, perhaps seven or eight years, maybe more, and bought it along with a 3½" and 5¼" enclosure.
They all had Prolific chipsets and all showed some problems under linux at that time, especially the two larger drives with USB/firewire interfaces, that may still be the case but I have been unable to find anything relevant from a very quick search.

Until I find a solution I have setup a scheduled reboot every seven days.

I have swapped the original HomeEasy HE861 PIR for another, mounted in exactly the same position, that seems to be behaving reasonably well.
Perhaps the first was simply defective.

February 2014

The RPi is behaving itself, rebooting every seven days with no lockups/lockouts since setting this up. (I see that ModMyPi now have 'tested' USB HDs available).

I have adjusted the thermostat on the boiler to lower flow temperature a bit rather than doing it through fhem - there doesn't seem any point in doing it the more complicated way. The 1-wire sensors are still monitoring both flow and return temperatures.

I have set up the fhem SYSMON module and I'm now using this rather than the RpiUtils mentioned earlier...

sysmon plots

My quarterly gas and electricity bills arrived recently, more to pay than the same quarter last year but to be expected with the autumn energy cost increases here in the UK.

Comparing meter readings form November to February for this year and last year I have used slightly less gas this year.
I don't have any weather data for last year so cannot factor that in but this year more of the house has been heated in a more comfortable fashion so I think the installation of fhem and the MAX system has been worthwhile.

A recent post on the fhem forum prompted me to look at the Cube timings again, more closely this time. I have been seeing regular log reports of 60 minutes time difference but all seemed to be working OK. In fact the actuators were still using CET, so an hour adrift from GMT.

Time to get the laptop out again and run the Max! software!

Using Wireshark I was able to capture the stream between the laptop and the Cube so I set the timezone to Europe/Berlin hoping I'd be able to find the Q0VUAAAKAAMAAA4QQ0VTVAADAAIAABwg string used in 00_MAXLAN.pm, then I set the timezone to Europe/London. Examining the stream, the timezone strings are quite obvious, all preceded by v:..

Wireshark snapshot showing GMT BST timezone string highlighted

Running the timezone strings through an online Base64 decoder produces the timezone abbreviation string along with a bit of undecoded data. Here's what I found..

The timezone list in the Max! software appears to be in five alphabetically sorted sections, from a brief look and play around the first section all appear to use GMT BST, the second CET CEST.
The third and fourth sections are as in the table and each a further hour forward for summer/DST settings. Europe/Samara and Europe/Volgograd both error here as invalid in the Max! software. I believe they both use the same MSK timezone.
The currently set timezone string appears in exactly the same form at the end of the decoded C: device message for the Cube.
From here it's a simple matter of replacing the timezone string in 00_MAXLAN.pm and reloading it.

So far all is now using GMT and not a single time difference warning. (Incidentally, my $time = time()-946684774; in 00_MAXLAN.pm is not altered).

I had previously set up my own HomeStatus code but have now transferred it all to the recently introduced RESIDENTS and ROOMMATE modules which define the state, location and mood of each member of a household, where state is currently one of home, gotosleep, asleep, awoken, absent or gone. It's all quite complicated with so many options, eg. setting up the transitions through asleep -> awoken -> home or through home -> absent -> gone.
My settings are based on the status of devices from the PRESENCE module, PIRs, time and my Home/Away switch.

I have split my fhem.cfg file to get rid of a lot of the additional TRX devices that appear when the RFXTRX433 is set to multiple protocols. I had these devices set as hidden already and their logs ignored but they clutter a single fhem.cfg file.
After adding an include ./FHEM/hiddenstuff.cfg to my shortened fhem.cfg, I reloaded but got a lot of log errors such as..

seems the 'include' needs to come after the RFXTRX has been initialised - common sense really, but it hadn't occurred to me initially.

I may separate out other devices as time goes on, MAX thermostats, 1-wire devices etc. but will make sure the files are included after initialising their respective devices. It seems a good idea, and probably generally good practice, to move all devices that require initialising to the top of fhem.cfg right after the global section.

Anyway, any more editing will have to wait until I get a new mouse, this one is depositing bits of previously copied text as I rotate the scroll wheel (it's configured to paste on middle-click). I have cleaned all the debris out of it but it's still misbehaving.

I have my Eco Switch and another switch beside it for when I go out but have often realised when en-route that I have forgotten to set them!
Once I have a reliable setup to determine whether I am home or not it would be useful to set this automatically if I forget in the future.

I wondered if it is possible to set the Eco Switch mode from software with a single command so tried from my desktop XP and the Max! software.
The Max! software has buttons for setting Eco, Auto or Comfort. I tried these and attempted to capture the stream in Wireshark.
Very quickly the stream stopped and the Max! software showed busy, trying anything the software said come back in an hour and try again!
I cannot be sure as the Max! software and my desktop XP have some issues getting on together, but it looks as though these buttons send to each valve in turn (through the Cube) and create enough traffic after a few changes to fall foul of the '1% rule'.
Before the actual send there is an option screen to choose either individual valves or all of them, anyway, I could not see any specific signal.

It looks very much as though it will be easier to do this through fhem, depending on whether I am home or not, simply cycle through each valve and set Eco, Auto, Comfort accordingly.

I have a new mouse, a supermarket own brand, it has a very stiff middle-click, manageable but I'm not really happy with it.
I will look for another soon when I visit somewhere with a decent selection as I think I need some bigger HDs too, I'm running short of space.

I have now split my fhem.cfg and have seven additional files. It makes fhem.cfg much easier to navigate. Most of my editing is through the frontend but it is handy to have a local copy too.

The supermarket mouse didn't work out too well, the stiff middle button caused me too many bad selects as the mouse itself often moved too. I now have a Texet mouse, better but not as good as my original.

I have found a few more timezone strings, now added to the above table along with Base64 hex decode. I need to test them all now before submitting a patch.

I see quite regular MAXLAN errors in my logs, perhaps one in an hour or so..

I hadn't really thought much about them as they have been appearing since I started adding MAX! devices and everything has been working as expected. Examining my early logs in more detail, it seems they became more regular as I added the sixth and seventh devices.
There don't seem to be any similar L: errors reported on the fhem forum so I don't think it can be happening to many others.

A few hours ago I altered my 00_MAXLAN.pm file from my $roundtriptime = 3; to my $roundtriptime = 4; Overnight and the following day there have been some errors, but many fewer than previously I think, so perhaps there has been an improvement.

I also wonder whether it could be a power issue. To start with my Cube was powered with its own supplied PSU, later on I switched to a powered USB hub shared between several devices. It's a shame I can't remember the exact date of the change.

I must try and remember to switch the Cube back to its own power supply once I have finished testing the timezones.

I'm still testing timezone strings, only one more to go now!

The Cube now has its own independent PSU, my $roundtriptime = 3; has been restored and I see perhaps one or two L: errors a day now, a vast improvement.
Perhaps the previous setup was affected by writes to the USB HD, its 5V supply was supplied from a powered USB hub shared with the Cube.

I'm backing up my data at the moment with a view to reinstalling (debian again, perhaps jessie this time) on my main machine, mainly to rationalise disk usage. I have 4 HDs with too many partitions spread across them, most unused now.
The disks total 750 GiB which is more than enough for me - so no new disk required.

I'm using grsync, copying the important bits first (everything is so scattered so would not be easy in one go) to a new 1TB USB HD connected to the RPi. It's a very slow process with a lot of data, network and USB share the same bus on the RPi, slowing transfer, and fhem is doing a great deal of logging too.

I intend for the new HD to be a permanent backup drive on the RPi once the new install is done and keep this up to date with the backup I carry with me..

I see that a new version of the Max! software has been released, 1.4.1, but so far I have found no reports as yet of its use or whether it's likely to break fhem and similar applications in any way. I believe it now reports current temperature of wall stats.
Very little news on this. One report says that firmware is not updated, just the web front end.

March 2014

I have reinstalled debian wheezy on my main computer and copied back all my data - so lots of free space now - and a regular backup strategy.

I tried to install debian jessie but the GUI was unreadable and unstable, I couldn't find any solution from a quick search so backed out, a PCI IDE controller card also caused me problems earlier on, reporting media errors when it appears it was swapping drives on the fly!

I found a nice suggestion here to automatically rsync to my portable USB HD as soon as it's plugged in to the RPi's powered USB hub - I often forget to backup until just after I've shut the desktop PC down.

fhem is running well, no major changes recently. The GMT timezone settings are working with no issues.

I am seeing more L: errors in the last few days so have altered 00-MAXLAN.pm again. No idea what may have caused this, I can't see that anything has changed.

I have just ordered four additional indoor HomeEasy PIRs so I will have one in each room.
These are more for detecting whether I am at home or not rather than for security, but that may change in the future.

PIRs have arrived and are now integrated in fhem. Testing my code for home/away seem to indicate I have it right.

This morning I awoke to a locked up RPi again and I was unable to access it from fhem web interface or via ssh.
Logs indicate that my new, supposedly supported, bluetooth dongle had locked the system generating hundreds of syslog entries.
The RPi was still logging but there was nothing in the fhem logs since last night.
The raspbian watchdog application hadn't triggered as it is set to monitor /var/log/syslog and that was still active.
I've now added a file check from an fhem log file too, though not very easy as most of my logs are updated monthly and therefore change name frequently - it seems /etc/watchdog.conf won't accept wildcarded filenames.
I have a couple of yearly files for weather logging so one of these will do - along with an alarm to change it for next December.

I have been a bit lax in updating this page lately. Little has changed with my set up for while.

I have updated the firmware on my HomeMatic usb stick. This is not the most straightforward of tasks! It took several attempts at flashing before success - and I was concerned that failure may have destroyed the device for good. One thing I did learn from this is that the time interval used by watchdog file watching is seconds - a series of repeated reboots meant I had to remove the HD and edit the watchdog config to get back in.

The 00_MAXLAN.pm module has now been patched so that timezone setting is now possible, rollover from GMT to BST worked smoothly here. I have seen no reports of others using this feature, perhaps all other MAX users are in CET/CEST areas.

I have a few other projects to get on with, a 1-wire counter board to build, based on an ATtiny chip, see http://www.tm3d.de/index.php/1-wire-device-mit-avr, and a Gertduino board to play with.

There is very little information available for the Gertduino apart from initial setup - which turned out to be quite easy. Now I need to find a use for it - and then attempt to implement it!

April 2014

I have just worked out my gas usage from the start of October last year and for the same period the previous heating season.

I'm not sure it really proves anything. The winter has been quite mild here, however, I have heated more of my home this year rather than just the necessary areas so it has been much more comfortable.

I attempted to install mpd to stream audio from the RPi. It was not very successful, load increased considerably and the stream constantly stuttered.
I will try again on my other RPi some time to see if I can improve the configuration in any way - reading the documentation may help!

I frequently come across advertisements and reviews of new products for home heating control. Generally these seem to be quite expensive, proprietary systems that do not allow third party expansion or extension.

I am very happy with my eQ-3 components and feel I made a wise choice. The basic components for an install are not expensive, a single Cube for control at around £43, wireless thermostatic radiator valves at around £25 each. That's it, all that's needed in many cases. Specific room temperatures and heating periods can be set with the supplied software on a PC and once set the wireless thermostatic radiator valves run on their own. Additional items are available in the eQ-3 range if required.

The choice of using fhem initially was that many other components and sensors could be used to interact with, modify and monitor the behaviour of the system as a whole or its various parts. This has indeed proved to be the case.

May 2014

It was all going so well and I have been hit with bluetooth issues again! Logs deluged with kernel bluetooth hci0 sco packet messages.

This seems to happen when I turn on my bluetooth enabled desktop machine in the morning. It causes so much activity on the RPi that it becomes unresponsive to ssh login or http requests. Thinking back to past lockouts, most, if not all of these happened shortly after the desktop machine was switched on.

I cannot find anything that will sort this so have removed the dongle from the RPi and will modify fhem configs - if I can remember what this will affect!

I see there is mention of a new kernel on http://www.raspberrypi.org perhaps this will help with bluetooth/USB issues. I'll watch it for a while before trying it with fhem.

I have now tried the 3.12 kernel. Load average showed at over 4 so I am back to a 3.10 version. (I have read that this is in fact not an issue but a matter of reporting.)

It has been a couple of weeks since I removed my bluetooth dongle. There have been none of the earlier problems with access and lockups since so I won't be trying bluetooth again until there is news that further USB improvement has been made.
(I have come across reports that there is a patch around that improves USB. It is not yet available via update. I can't remember exactly where I found it but think it was on one of the RPi audio/multimedia distro forums.)

For years I have had BBC Radio 4 on in the background for most of my day. Recently programming and editorial styles seem to have changed significantly. I find there is very little that interests me any more so I have made another attempt at getting mpd running.

This time I have mpd on a separate RPi plus HD with a Wolfson soundcard attached along with a pair of USB powered speakers - the whole lot running off a single 2A USB PSU. Control is via GMPC on my desktop or the MPD module in fhem.

The Wolfson is impressive though control is very much CLI at present and the card requires either Wolfson's own kernel or a self-complied version, though there is a patch available for the 3.10.25 version. Hopefully there will be integration with the main RPi distros soon.

For anyone struggling to get the Wolfson lineout volume control working in mpd you need the following in /etc/mpd.conf

Another bit of hardware I have acquired recently is a Monkeyboard DAB development board from Cool Components. There are example tutorials on the Monkeyboard site though it's not really suitable for use other than with CLI in linux at present.

I have no real desire to listen to DAB with its generally poor bitrates - and it appears I live in a DAB blackhole, but it does have an FM tuner as well.

Sadly DAB in the UK seems to be going the way DVB has gone since its introduction, prioritising quantity over quality.

I have started a page of code fragments from my fhem setup. I found that examples by others, both on the fhem forum and elsewhere helped me get started.

Don't expect anything clever, just the basic stuff and my poor coding ;)

I recently built a 1-wire environment sensor (as shown here Umweltsensor and managed to get some readings out of it that generally make sense. I still have to get hold of some UV film to reduce the voltage generated by the TSL260 as suggested in that text.

However it seems that I have a problem with power supply voltages! The pressure sensor plots have odd spikes in readings, a closer look shows Vs is significantly lower than the minimum specified 4.85V as these occur.

The Sheepwalk RPI3 1-wire adapter has a jumper to allow external powering of the 1-wire bus.
Switching this has helped but today I'm seeing min 4.82V and max 4.89V so still out of spec (measurements taken on the 5V line of my 1-wire bus - non-parasitic).

I need to think about a new supply, perhaps a single high power unit for all the related 5V devices.

For reference, at present this is supplied by a 4-port hub and 2A wall-wart from ModMyPi, shared with my RPi, HD and a network switch/hub (supposedly 500mA requirement).
I suspect I'm just asking too much of it rather than it being faulty. (The HD is one salvaged from a broken laptop and is quite old, perhaps around 10 years. It is probably less efficient and more power hungry than modern equivalents.)

Watching the voltage plots since my last entry certainly seems to show issues with low values occurring as RPi/HD activity increases eg. during updates and backup.

I have been comparing my pressure readings with those provided by the Yahoo weather fhem module but that has been showing the pressure frequently dropping to 982mb, sometimes for long periods.
This changed yesterday and it has become more stable. It may be specific to the location I am monitoring.

My readings look to be generally good - they fit between the isobars on the UK Met Office charts too.

I think I have more evidence of power problems.
I came home the other evening having been out most of the day, switched on my PC and attempted to access a few fhem web pages to see what had been happening in my absence.
The first page came up but nothing more, all the rest waiting for the server to respond.

My guess is that trying so many pages all at once increased load on the RPi and HD so much that the PSU adapter was unable to cope. There was no logging once it reached this state so unfortunately I have no supply voltage data.

A reboot has brought everything back - but it shouldn't be necessary.

June 2014

I now have a high spec PCM50US05 5V 8A PSU and have made up a number of splitters and leads to power all my various devices from it.
All is looking good so far and overall the wiring is somewhat neater, not having so many small PSUs and often too long USB leads all over the place.

I still need to make a few better leads to reduce possible high resistances in some.

I have been otherwise occupied recently digitising my vinyl collection - again (I overwrote a previous effort a long time ago rescuing someone's dead PC).
There are too many boxes, LPs and cables strung around the room at the moment so uploading this will have to wait until I have finished recording.

It is a very slow job, starting with washing all discs to remove several decades of debris left from playing in smoke filled rooms and the accumulated dust from two house renovations.

I am recording from the tape output of my Rotel amp into the Wolfson card linein. Amplitude of the recordings is low but the quality appears to be good overall.
My ears are old now and I take the view that as long as what I hear is close to that of playing the vinyl itself I will be happy.

Earlier testing has caused me to abandon the automatic de-click and denoise functions in gnome wave cleaner. Others have found it to do a reasonable job but it doesn't work for me, too much noticeable degradation.
Instead I remove the most noticeable clicks and scratches using manual declick, amplify the whole by a factor of two then split into tracks using wavbreaker. Editing the exported wavbreaker offset file allows the splits to be renamed to final track names.

As mpd plays I flag any files that need more attention - well, it may be some years before I have worked my way through them all but so far it's a method that's working for me.

July 2014

Suddenly it's July!

I have finished an initial digitising of my vinyl collection, split out all the tracks and encoded them as flac.

I intend going over them all again, as I get time, to tidy things, remove some glitches and re-record a few poor tracks. (I suspect my frequent use of the kettle for cups of tea may have introduced a few electrical spikes!)

I made up some new cables a while ago for powering the fhem RPi and associated bits but have only today got around to fitting them. They seem to have made a difference to voltages on the 1-wire devices, see the image below and the difference at around 17:00.

The PSU output is via a 5-pin DIN plug and all I had to start with was an old audio lead with a 5-pin DIN socket and very thin cabling attached to a moulded plug.
My new one uses 6A mains cable - not easy to solder to the small DIN tags!

Voltage plot as read from DS2450

The 1-wire bus is powered independently of the RPi, although from the same 40W PSU, activity on the RPi and other peripherals, including two USB hard drives, was affecting the 1-wire bus voltage as can be seen by the low spikes in the plot.
The new cable has improved things greatly.

The PSU output is measuring about 5.03V. I'm not able to easily measure TP1 to TP2 on the RPi as the points are hidden by the Sheepwalk 1-wire card.

Although not really related to fhem, I have obtained both a standard and NoIR RPi camera with the intention of snapping some of the wildlife that visits my garden.

An attempt last night using motion-mmal produced a lot of very dark images. I think I need some IR illumination for decent results.

Today I have set up the official v4l2 RPi camera driver with the Raspbian version of motion. The framerate is certainly much faster though I doubt it will make any difference to results at night.

Last night produced fewer images but they were very clear - not of wildlife but several truck tail lights on the adjacent road!

Illuminator installed but not going quite as well as hoped. The illuminator is at about 2.4m high, the camera pointing out of my kitchen window. I think the light intensity is too low and all I see is what looks like a dark shadow.

Next step is to try the camera out of a closer window with the ground illuminated from almost overhead.

I have a Raspberry Pi B+ now!
I had expected a reasonably straightforward swap for the current fhem RPi but it's not working out that way.
The B+ will sit happily on my desk and boot from the fhem HD but as soon as I move it back into position it refuses to boot at all.
Not easy to get a monitor feed there so no logs to look at.
I don't think that power is an issue here as the HD has a separate feed from the 8A supply.

I will try and get another less power hungry HD and also make up a new power lead for the B+. The old lead is a hacked and very thin pound shop phone cable but even bypassing that has had no effect so far.

A fresh raspbian install won't be a bad thing anyway.
NB. When moving root filesystems between B and B+ machines you are likely to lose eth0 unless you move /etc/udev/rules.d/70-persistent-net.rules out of the way so that a new one can be generated matching the hardware.

Whilst messing about with all this I plugged my cheap power meter inline with the new PSU. It is currently showing 0.11A, 12W, with the following attached..

August 2014

I am really not getting very far with the B+ and and an HD.

I have tried many different install methods but gone back to the _installer_08-19-12 that I have used so frequently in the past. This no longer works as is for the B+ but will if bootcode.bin and start.elf are replaced with recent versions.
However, my new Seagate Expansion 500Gb drive is not recognised at all during install. (Even a USB stick requires manual intervention during partitioning using the modified installer.)

I have been able to install successfully to USB stick - but it falls over after copying -update boot files to the SD card.

I have copied a successful USB install to the HD - but it fails to read the drive.

I'm not sure where to go from here but I think I will leave things for a while.

My most successful attempts so far have been with my old HD so I may go back to that and try to find out why it seems to fail when moved to its fhem position - maybe what I should have done in the first place!

I am reluctant to use the Noobs raspbian version but I did try it.
It seems to only want to install to SD, with no real swap and pulls in so much other stuff that I don't want.

A few days later and I am no further forward except that I am beginning to think that my B+ is just over sensitive - and possibly defective.

As soon as I add max_usb_current=1 or safe_mode_gpio=4 settings to config.txt the B+ refuses to boot (a repeated quick flash of text then a rainbow screen), I assume it thinks the supply voltage is dropping too low. It's possible of course but..
I have four 2A USB PSUs, all from reputable UK based RPi suppliers and have tried each of them with some half a dozen different µUSB leads.
I have tried a feed from my desktop computer with the same result. All these tests done with nothing but a keyboard plugged into the B+ - and I even tried that through a powered hub.

Next move might be to get hold of another B+ to compare it with when I next do an order, along with another, > 2A PSU.

I now have another B+.
This one works as expected so the first will be returned. (The above problems with installs are probably not typical of a good, working B+.
Install to a USB stick is fine, but I didn't bother trying to HD but suspect that an independently powered HD would be OK.)

After a few tests and a bit of playing around it has now replaced the B running fhem. All was fairly straightforward but there are some differences, mainly to do with power!

My butchered very thin pound shop µUSB power lead proved too thin for the B+ causing the power LED to flicker slightly so that has been replaced. The LED is now steadily lit.

I have been running a 1TB Seagate Expansion HD, entirely from a powered hub so I can easily backup my desktop and other bits.
The B+ does not like this at all so it is now disconnected. I suppose there must be some current draw from the B+ to the hub, I can't see why there should be at the moment so will think about it some more and perhaps look out for a cheap USB power meter. (I have not spent much time on this yet but it seems that the Seagate takes a considerable time before it is actually ready to read.)

I have also added a PiRack so that I can use the Sheepwalk Electronics RPI3 1-wire adaptor - and a Piface Digital and Piface CAD. They are all working perfectly happily on the B+.

I decided to re-use the now redundant B by adding a standard RaspberryPi camera.
All was going so well, I completed the install, set up motion, took some shots then file system errors!
This was running from a quite new Sandisk Cruzer 8GB USB stick which is now totally useless, showing read only, write protected at everything I have tried.
It seems they are quite well known for it!

The B+ is proving to be very good, possibly more stable than the B it replaced however that could be due to the now replaced inadequate power supply lead.

I have not been able to test the HDs for power requirements as yet because the USB meter I ordered from CJE has not arrived!
They do state to allow 28 days for delivery but I didn't actually expect it to take that long. Lesson learned I guess.

I have set up LCDproc to talk to the Piface CAD , displaying system stats.

September 2014

A long time since I updated this page!

I attempted to write a module for LCDproc - with limited success. It worked but I wasn't happy with it, probably because I didn't understand as much then as I do now - and that's not much!

After a lot of thought and reading I wondered if ECMD and an ECMDdevice might work. It did, but I could not devise a way to catch the seemingly random messages that LCDd issues without prompting. So back to writing my own module...

This one is better, and it works, currently displaying SYSMON stats as the Readings change.

There are some issues, mainly that as we are not dealing with a physical device and there is no way of extracting screen or widget information (once sent) from LCDd, the screens etc. have to be recreated on a new start.

It's been almost a year since I started this project. Looking back, even at this stage, my energy usage for hot water heating is much lower than for last summer. Heating energy comparison is more difficult, I have certainly used less that the previous year but many factors, such as weather or days away, can affect results.

I am also beginning to think about the high load on the RPi, it's constantly hovering around 1.9/2.1. Whilst it is coping at the moment, I guess that there may be issues once the heating season starts and activity increases.

I may try moving the mail, news and syslog servers to another RPi and see how much difference that makes. Perhaps also attempt to run fhem on two RPis with fhem2fhem.

I have managed to acquire a copy of 'Weather Toys' by Tim Bitson at a reasonable price and in reasonable condition.
Quite surprised how thick it is at 2.8cm and 471 pages, I had assumed it would be a thin paperback, it will keep me busy for a while.

October 2014

... and it's getting chilly! The heating is now on, though not much yet.

After a great deal of online research and thought I've just taken delivery of a Cubietruck. See also the wiki page. It's sold and described as a development board and has an ARM Cortex-A7 1GHz dual-core processor. Working with it is not nearly so straightforward as with the Rpi - and there is next to nothing in the way of documentation!

I do have some concerns about the number of reports of dead devices but think it's worth the risk - we will see! It comes with Android installed apparently, but I have not tried that. Compared with the RPi the Cubieboard community is much smaller and there is no 'standard' or recommended alternative OS.

I want to run debian on it and transfer fhem once I am sure it is stable. Thankfully, as a latecomer to the platform, there is now a quick and simple way to do it - as well as a 58 page thread detailing the story!

Igor Pečovnik provides a single download for creating a µSD card image. Using this the Cubietruck boots, regenerating SSH keys, setting MAC address, resizing partitions and downloading the package lists. A second automatic reboot loads the new system and you can then login via SSH. All in all, very easy!

To date that is all I have done. I am expecting a new 2.5" SATA drive early next week and will transfer the OS to that - using the provided script. Booting still requires either a µSD card or install to NAND, I intend to stick with µSD in the hope that I at least avoid any NAND corruption.

The new SATA HD arrived, transferring the OS to it was easy and it has been running for several days now - unfortunately not very well!

It has crashed once every day and twice this morning. There is nothing in the logs to indicate why. I have disabled ramlog in the hope that I don't miss anything on a sudden crash.
I have just installed Igor's v2.6 kernel rather than than the v2.7 I started with just in case it provides more stability but it's just crashed again after running for some 20 minutes!

Further attempts at booting seem to get no further than reading the SD then an abrupt shutdown. Replacing the v2.7 files on SD results in the same!

Suspecting file corruption on the HD I later ran fsck which says it's clean, I can read log files etc. but there is nothing useful to see. Unfortunately I didn't check the SD card but it should not have written to it - I think. Something, somewhere is not right.

Very disappointing. I really need to upgrade to something more powerful for fhem... after a recent spell of logging at verbose 5 causes the RPi to hang on viewing the log!

I may have a been a bit premature in condemning the Cubietruck so soon. Embarrassingly I am beginning to think it may have been a power issue.

I contacted the supplier who suggested I try a reinstall. I must admit to being a little reluctant as I couldn't see any way out of the crashes.

I have reinstalled and it's running on the SD card and it has now been up over 24 hours with no problems. (HD is still attached and powered but not in use.)

This time it's on its own dedicated 3.5A PSU rather than the 8A shared with everything else. Even with the Cubietruck attached to the shared supply it was only registering 14W in total so there should have been plenty in reserve - but I had to feed it through a powered USB hub as the Cubietruck DC barrel connector has a USB plug! I have a feeling that the hub, though of good quality, may have limited the power available to the Cubietruck.
Doesn't explain the sudden onset of abrupt shutdowns though.

I hope to let it run like this for a few days and then move the filesystem to HD, if that runs happily for a few more days I will try it on the shared power supply again, but with a proper power lead.

November 2014

The Cubietruck has been running well, with no problems at all since my last entry. I took all my networking and fhem related stuff apart and moved it into a small wooden cabinet. It's a bit cramped but takes care of all the bright and flashing LEDs and rat's nest of cabling.

The whole lot is fed through a powermeter adapter and is showing a steady 25W. Not bad I think for Cubietruck with HD, RPi with HD, 8 port network switch, 7 port USB hub, Gigaset IP phone base station, Vigor 120 and m0n0wall (with wireless card running on an Alix 2d3) plus the USB devices and Cube of course. Nearly forgot... I have added a bluetooth dongle again - no issues with that so far.

fhem was finally transferred to the Cubietruck last weekend with few issues - there would have been fewer if I had transferred the statefile too!

The difference in performance is astonishing!

The RPi is still running with quite a high loadavg even without fhem. I think LCDd may be partly to blame for that.

Today has been spent trying to resolve a couple of errors, the first spews a few lines on saving the config, the second a few more at startup.

The errors on saving were caused by two definitions that had empty attribute fields. I don't remember adding them so guess they are from the original autocreate code and may have been there for up to a year. Recent updates have highlighted them.

The startup errors seem to be from the 10_MAXLAN.pm module but I have yet to get my head round that one!

I have now completely rebuilt my fhem.cfg from scratch on the Cubietruck and things seem better. I cannot see any obvious difference between the current cfg and the previous version. Setting it all up again took a while though!

All is running well, heating is on for much of the time now and under fhem's control - and my weekly gas readings show a reduction in units used month on month in comparison to last year.

December 2014

I haven't added any images for a long time so here are a few...

This is made from three separate readingsGroup entities. See http://www.fhemwiki.de/wiki/ReadingsGroup

rg_Heating is very similar to the config in the wiki but adapted for my MAX devices.

It shows me the state of the devices and allows me to increase or decrease desired temperature for each valve.

There is additional code in the wiki that needs to be saved in 99_myUtils.pm that has not been included on my linked page.

rg_Indoors shows a selection of values from my various 1-wire devices and rg_Weather values from my weather station with pressure from a 1-wire device.

All three are combined in a single group using the column attribute in FHEMWEB.

my heating control using the column attribute in FHEMWEB

This is made up of a number of real and dummy devices that interact to provide control of boiler and pump switching through code in the various notify devices with a bit more in 99_myUtils.pm.

Boiler and pump switching times and duration. See http://www.fhemwiki.de/wiki/HourCounter

The boiler and pump switch plots are offset by differing amounts to separate them from the main plot section.

The switch plots show a noticeable (intentional) difference to start the pump before the boiler and allow pump overrun.

Note that this shows power to the boiler, not to the burner, power to the burner is controlled by the boiler's own internal thermostat.

MAX valve settings displayed with logProxy. See http://www.fhemwiki.de/wiki/LogProxy

An interesting recent addition to logProxy is a polar plot.

I have added valvepositions to the basic configuration. Ideally these should be scaled as at high values they flow outside the plot boundaries.

MAX valve and weather display with logProxy

I added this recently for several valves so that I could see if there was any obvious correlation between heating demand and weather. Nothing obvious yet.

Note the horizontal reference plot at 0° C.

My current project is a display similar to the one in the first post of http://forum.fhem.de/index.php/topic,28025.0.html

I have very little experience with Arduino, what I have is from playing with a Gertduino board. I have acquired some Neopixel strips, a Uno R3 and a Pro Mini - just in case I can get it all to work!

I have been playing with various examples and those given in the Arduino Cookbook to familiarise myself with it all.

The code for the display is available from https://github.com/hdo/arduino_statusdisplay but the author's fhem statusdisplay module does not seem to be included - or available from anywhere else.

I could not get this code to work at first in the Arduino IDE - probably due to my lack of ability. I tried eclipse but the learning curve is just too great for the moment, perhaps I'll try again once I am more familiar with Arduino stuff.

I am trying to work with the light_ws2812_Arduino library rather than the light_ws2812_AVR that the author appears to be using. Early days yet, but I may get it all to work!

Last day of 2014 so officially into Winter now, fhem is still doing well and keeping me warm!

Since installing in October 2013 all devices except for one MAX stat and one window switch are still using the original supplied batteries.

I have received several mails during the course of this year saying these pages have provided some useful information.
It always feels good to get positive feedback like that, so thanks for those.

The statusdisplay is coming on slowly, the Neopixel sticks are working and controllable. I plan to add a piezo buzzer for audible warnings - it's all coded and ready to test, just waiting for some reed relays.

I have quite a few buzzers here, most of them active and single tone but one is 3-tone and quite loud so I hope to use this. I think it's a Maplin's Code: KU60Q - if you can find it on their very poor website. I have tried to find a proper datasheet for it without success, but it works fine on 5V, plenty loud enough for my purposes.

The relays are to switch the main buzzer rather than direct from the Arduino pins and then to switch the additional connections (orange to green or yellow to green). Once they arrive I will set everything up on a breadboard before putting them permanently onto perfboard - assuming it all works! Finally moving the code from the Arduino Uno R3 to a Pro Mini.

Of course, once those bits are working I then have to be able to control it all from fhem - guess that calls for a module so still some head scratching to do for a while.

If it all comes together I will add details.

Incidentally I am doing all the above on a RaspberryPi running raspbian jessie - and a £10 charity shop monitor.

jessie installs later versions of the Arduino IDE and Fritzing than on my desktop wheezy install. Yes. it's slow, but it's fun too!

...and another note that for the last few months I have been using bluefish to edit this and other pages.
For many years I used kompozer (and before that its predecessor Nvu) but kompozer became increasingly unstable as development slowed but its various dependencies were updated.

That's all for 2014, hoping 2015 is a good year for all.

January 2015

First week in January and my Cube has forgotten all MAX! devices so no heating this morning! IODev for all devices has no value, normally they show the Cube.
I have no idea what may have happened, no sign of network or power issues, nothing odd in the logs.

I tried many things with no luck so I removed a couple of rad stats and reset them, then paired to the Cube.
Both OK and recognised but obviously at default values - same device-ID though.

The rest of the devices I simply re-paired in situ, again back to default values.

So I've spent some time today recreating and reloading weekProfiles and other settings. (I now have my weekProfiles all backed up just in case!)

I hope this is not a sign that the Cube is going to die. I'm wondering whether to get hold of another as backup, I don't really want my heating to fail in the middle of a really cold spell.

Looking through the MAX board on the forum I came across a thread from 2013 mentioning this. Seems it happens sometimes with no idea of cause.

It would seem to be within the Cube I guess, perhaps a firmware issue, stray radio signal, who knows what?

With luck it doesn't mean it will fail soon. My fingers are crossed!

I am still doing bits to the statusdisplay but keep getting distracted.

I have started a new page with details so far.

I got sidetracked again!

I tried to create a means of changing weekProfiles for MAX! stats using a readingsgroup along the lines of this
I managed to get as far as creating a page displaying all values but the data required to get this far was immense and response times impractical. I posted details and an image here.

This prompted another user to post his solution (continued in the MAX board) so it was worth my effort I think.

The Arduino sketch for the statusdisplay is complete now but will probably require a few adjustments over time. I have the basic structure for a module but really need to assemble everything when I find time.

I have just ordered some panStamps and associated bits. They look really interesting but there is so much information to try and absorb.

I think it may take some time to understand it all and put it to practical use. The forum looks helpful though.

I have just added a panStamp page.

February 2015

Not really related to fhem but it may help someone else searching the web...

I have just updated my B+ running owserver to the latest 3.18.5 kernel.

This one, as well as some of my Bs boot from a card with a single FAT32 partition as root is on USB.

It seems this is no longer possible, the B+ at least will no longer boot, it is looking for a second partition, mmcblk0p2. Of course I don't have one.
Resizing the FAT32 partition and formatting the remainder to ext4fs is enough to enable booting again. Odd.
If this is a permanent change rather than an oversight, I may have to get new SD cards as a few of the Bs have only 64 or 128MB cards. I think I'll leave updating them for a while.

I posted about the single partition issue on the RaspberryPi forum but there seems no reason for it to have happened.

I updated one of the other Pis that boots from a 128MB SD card - and all went well, no issue at all with just a single partition.

I also tried to do an update from a 3.18.5 boot single partition SD card to 3.18.7 on a B+ - and that went well too! Perhaps there was some issue with an update from 3.12 to 3.18 initially that is gone now.

My RPi2 stopped booting! I tried all the usual tricks with no luck.

On closer examination of the board itself the L2 choke appeared to have lost its top and sure enough the top lay on my desk close to where the Pi2 had been sitting since being set up.
The choke was actually split through its core, with the copper windings in the bit that fell off. It has not been subject to any rough treatment in my hands so I can only suspect factory or transit damage.

It has gone back with an RMA and hopefully will be replaced when new stock arrives. I already miss its impressive performance over a B+.

April 2015

Another Winter nearly over. Not very much to add here, all has been going well with fhem.

Some time ago I added a Calendar to fhem to remind me of when the various bins/waste collections occur.
I exported an ical file from a desktop organiser and saved within the fhem files.
This was based on the forum threads here and here.

I found the ical format rather bulky and not obviously easy to interpret or modify - and the notify writes to the log file every time it's run (not a problem but I found it a little annoying).

I came across another post with a nice looking format for the same thing.

waste collections in a readingsgroup

This is based on a readingsgroup and a special holiday file containing just the collection dates - all very well but how to create the holiday file without adding each date manually?

I knocked up a quick 99_myUtils.pm subroutine to create such a file given start date and interval. It won't suit all variations but should give anyone an idea of how to make a start.

My environment sensor (Umweltsensor) started playing up the other day. For some reason the reference voltage (used to calculate barometric pressure) dropped to zero.
All looked fine visually and nothing seemed to have changed with 1-wire implementation.
I re-soldered all joints and gave the board a good clean and all is working again. Perhaps there was a poor joint or just a bit of flux residue and condensation.

Following an update to fhem a few days ago a couple of my FileLogs stopped logging!

These were both hastily put together to log daily and monthly reading of energy consumption using the FileLog regex wizard. I set them up to log many events until I am sure of what I need - to be refined later.

The definition of the daily log is (caution - may be wrapped!)...

It seems fhem.pl has been modified and as a result only the first regex is acted upon in cases such as this!
Enclosing the regex string in brackets restores the intended behaviour...

When I first started with fhem, before the wizard was introduced, I always enclosed such strings in brackets, it seemed logical at the time and makes the definition/expression easier to read.

I will try and remember to do the same in future.

NB. The relevant patch to fhem.pl has now been reverted so my original setting should work as was.

June 2015

Nothing much to add this month as it's Summer here and all is running smoothly, however I thought it may be an idea to look at updates and restoring should an update break things.

fhem updates are released at 07:45 CET/CEST which is 06:45 in the UK. I will often check for updates around this time but I do not install until I have checked the fhem forum for any issues.
Problems are usually reported very quickly so by 07:45 GMT/BST I generally know if it is safe for me to update.

Some time ago the update method changed slightly although the

and

commands remain the same. Modules that have been updated are backed up so that they can be restored quickly and easily.

To list what backups you have enter

and you should see something like

In order to revert the latest update on my system I would enter

followed by the usual

of course.

Time for a moan ...

I have bought a lot of stuff from CPC in the past and used to browse their site regularly - often adding bits to a list and then buying more!

A while ago they updated/upgraded their site and it now frequently freezes my browser. I am sure they would advise me to use a 'supported' browser but that is hardly the point of the web.

For general browsing I use konqueror or rekonq (debian wheezy, kde)^[1]. I have other browsers available but choose to use them for different purposes.
Generally I get by but if an organisation makes viewing their site difficult or impossible then I go elsewhere - their loss.

For my own security, when placing an online order I use a separate, rarely used but always updated, machine and either iceweasel or firefox (debian wheezy or linux mint).

(CPC are not the only site I have issues with by any means, there are others I do not bother visiting at all any more).

^[1]To be honest I don't make it easy for the current generation of web designers, I reject almost all cookies (if an organisation wants to store information about me they should use their own resources, not mine, cookies rarely enhance my browsing experience!), I don't have flash - or even many other video codecs installed for that matter. Many social networking, advertising and tracking sites are redirected to localhost too. These measures do enhance my browsing experience.

Within a couple of days of writing this...
I received a mail requesting customer feedback on their service in general. I completed their survey based on the my current experience and stated that their website no longer works for me... nothing has changed yet.
As is often the case, these surveys only allow answers that they want to hear - so it's rather a pointless exercise filling them in at all.

July 2015

Seems CPC have changed their delivery methods too. A recent order arrived in two separate packages, the first arrived next day by carrier. The second was sent via Royal Mail.

Royal Mail have recently reorganised rounds and deliveries here, they seem to have scrapped all their bicycles and replaced them with vans, changing the rounds at the same time.
I am now at the end of a round, the time they reach me is unpredictable.

I had to collect the second package from my local Sorting Office three or four days after placing the order.

CPC have a vast range but their prices are not the best. In the past I have always considered the additional cost worth the extra in that every delivery I have had from them up to this one has been next day.

August 2015

Another carrier issue!

I placed an order last week from another supplier, all OK and received a delivery mail with a one hour timeslot around midday from InterlinkExpress.
All sounded good - except delivery time came - and went with no sign of InterlinkExpress.

I waited - and waited. Nothing!

At around 7pm I received another mail from InterlinkExpress. They claimed that no-one was available to sign for the package and they left a card.
No-one visited here other than my usual postman. No-one left a card!

Are their systems really so bad that it takes around six hours to tell me that there was a problem with my delivery?
Other carriers have notified me within minutes that I have just received and signed for a package.

I called Customer Services on the number given - it's an interactive menu driven system. There is no way to speak to anyone to make sure that another attempt at delivery arrives at my address and not wherever they tried to deliver today.
No option even to leave a message.

Another number I tried connects to a similarly useless system.

I could arrange to collect the package from one of their Pick-up shops - except that their website is so broken that I cannot see, let alone choose, any Pick-up shops.

I am still waiting for replies to my mails to InterlinkExpress - and the supplier - in the hope that they can at least speak with someone.

This is the first time I have had an issue with carrier delivery, also the first time I have had any dealings with InterlinkExpress I believe.
I am not impressed!

I received my order the following day with help from the supplier Label King.
Still no reply to my mails from InterlinkExpress.
I have no idea whether an attempt was made to deliver to the wrong address or whether the driver simply couldn't be bothered.
Very poor that there seems no way of contacting them other than through the presets on their web pages that do not appear to allow any contact with, or response from, a human!

I have been tinkering again, nothing major, just a bit of tidying up.

For a long time I have been plotting weather history at home, my history plots now look like this...

Weather history

The values are all from a yearly average log to which all my daily average readings are saved.

It would also be useful to have accumulated rainfall values so I have added a few bits to the rg_Weather readingsgroup mentioned much earlier on this page.

It now looks like this with the additional rainfall values...

rg_Weather revisited

It requires a bit more code and modification of the readingsgroup as given here.

This is another readingsgroup that shows values from my panStamp temperature/humidity devices, it also includes the new $max and $min functions.

These functions are not fully documented at this point - I have no idea how to alter these eg. to reset values.

RoomInfo

You may have noticed that the suffixes for the max and min temperatures are wrong although I'm sure they were correct at some point yesterday!

The valueFormat attribute cannot distinguish between the two max and two min entries and is using the last applied format for both - hardly surprising as they have the same name.

This one is better...

RoomInfo

The answer is to add an alias to the calculated entity and use the alias for formatting.
I am not sure this is giving me exactly what I am after so I may try the statistics module and use readings from that.
An interesting exercise all the same :)

Earlier on this page I mentioned reliability issues with the Pi, random crashes and lockups.

These are very much a thing of the past, mainly due to a decent PSU I suspect.

I think the last reboot on the Pi was for a newly installed kernel, not sure about Cubie, possibly a watchdog restart...

October 2015

Autumn and the heating season is here again!
Disappointingly I am waking up to a cold bedroom.

It seems the batteries in the stat have died - possibly rather suddenly as I didn't receive a 'low battery' mail back in August when logging stopped.

To avoid this happening again I have added a new section to 99_myUtils.pm, see Device_Status on the fhem snippets page.

I have acquired a UPS, an APC Smart-UPS 750, SUA750I (sine wave output not the more usual stepped sine wave).
Seems to date from 2008 but working OK.

I don't have many power outages here but do occasionally get reduced voltage levels. Probably a few spikes too as lines are overhead.

A benefit is that it allows me to perform any electrical maintenance without having to shutdown fhem and my network hardware, it will run these for over two hours before shutting things down using NUT on the Pi (tested of course).

I am in the process of upgrading the Pi that does my 1-wire from raspbian wheezy to jessie.

Rather than try and upgrade my existing wheezy install, which may end up a bit messy, I am starting with a jessie from scratch.

In preparation I have cloned the existing Pi HDD to my desktop using rsync as a backup and reference for current configs.

The new install of jessie on another Pi is straightforward.
Default is to boot to lxde desktop, easily changed as is the removal of a lot of big and unwanted packages.

Next step is to clone the root partition of the SD card to a USB stick, then alter jessie default configs on the stick to match my current settings, including changing user Pi, passwords, Pi sudo settings etc.

Note: setting a static IP address is now done in /etc/dhcpcd.conf not /etc/network/interfaces as before.

/boot/cmdline.txt needs altering to point to the new rootfs and /boot/config.txt to add overlays etc. after having run raspi-config for other settings.

All seems OK so the changeover should be painless and not involve too much downtime.

The rootfs will obviously need cloning to the existing HDD so will have to be done off-line. Fortunately, this being a new install, it is quite small.

To finish this off I have to wait for the arrival of a Sheepwalk Electronics RPI3 v2 1-Wire Host Adapter to replace my original (26 pin) RPI3 that is currently sitting on a Pi-Rack on the B+ along with a PiFace-CAD and PiFace-Digital, both now redundant.
All that makes for quite a tall tower so it will be nice to be able to reduce its height.

Vaguely related to the above, I am considering moving fhem back to a Pi - or more specifically a Pi2.
I have had no problems at all with the Cubietruck but it will fail and need replacing someday, no doubt with different hardware and all that is involved in getting a completely new system up and running again with minimal disruption.

At least with a Pi2, a second one as a backup, is not expensive - and Pi2 is more likely to remain in production - or at least to have a compatible successor.

My move to a Cubietruck was due to poor performance at times on an original Pi B, particularly when generating and viewing plots.
I think a Pi2 should be able to handle this much better - it will also free up one of my few IPv4 addresses (I am mostly IPv6 here but some devices are IPv4 only).

Perhaps performance could be improved by switching to DBLog from FileLog logging - the problem is that I don't know anything about SQL databases :(

Some things for me to play with through the winter :)

I am still very tempted by PCengines APU boards, especially the recently announced prototype apu2b4. I have found their Alix series very reliable. Perhaps an upgrade path for the future.

November 2015

fhem is now at version 5.7 and there are some notable changes particularly regarding the notify command.

The announcement is here and details are also set out in commandref.

Major changes are that..

@, % , %NAME , and %EVENT are no longer permitted and should be replaced with $NAME and $EVENT .
@@ and %% should be replaced by a single @ or % .

Failure to change these at upgrade will show errors in your logs, but at least they should be reasonably obvious from the description - unless you have many unchanged!Of course you may not see these errors logged until the notify is triggered.

December 2015

Nothing really to add this month so far, all is working well - but I have spent some time tidying up web pages, especially css stuff.
My stylesheet links were broken!

I hope I haven't broken too much!

I have bought a couple of RFBees to install CULfw - just in case my Cube or HMUSB stick fail.
I have a mySensors gateway on its way to me too.

I thought it was about time I caught up with git so decided to install as a server on the ex-fhem Pi B+ running 1-wire.

It didn't go well.
The Pi would not recover from a reboot.
I suspect I missed transferring the /boot files to SD card manually after a recent kernel update (I don't do installs like that any more!).

This seemed an ideal opportunity to swap with the ready and waiting half-configured Pi2 running jessie and get rid of the PiRack and other now redundant bits.

All went well other than a few silly mistakes such as forgetting to set static IP in /etc/dhcpcd.conf :( - and everything looks much neater.
I have git set up as well, I just need to read and learn how to use it.

fhem is still running on the Cubietruck. I don't intend changing that until the heating season is over.

A new fhem module for storing and setting weekprofiles has just been released.
It looks very promising so far.

March 2016

It has been a long time since I last updated this page.

fhem has been running smoothly through the winter so far.

I have added the GasCalculator module in addition to my own gas calc bits. It provides additional usage and billing statistics.
Initially it took me a while to set up as it requires a counter not just a simple tick counter.

I recently bought a Louis Swart 1-wire LCD from http://www.fuchs-shop.com/en/ to add to fhem and my 1-wire network.

Unfortunately it is not working as expected on my jessie Pi2 with its Sheepwalk Electronics RPI3 1-wire host adapter.
It misses the first character and adds a || at the end of each line. It also requires two digits to control the backlight, not one as it should.

I set up another Pi2 with my old 26 pin RPI3 to check this out.
As would be expected a jessie install shows the same behaviour as above but wheezy works as it should.
jessie has owfs-2.9p8, wheezy owfs-2.8p15 .

Installing the 2.8p15 1-wire debs on jessie after removing the jessie versions corrects the behaviour in jessie.
Seems something may have got broken in the later jessie package, perhaps it applies to debian/raspbian only, but I have no way of testing with only the Pi hardware

There may be fixes in later versions of course but I am not sure I'd be able to install from the raw 3.1 sources and cope with the systemd stuff - and without that I don't feel I could confidently submit a bug report

Latest snapshot (owfs-3.1p1) builds fine but shows the same issues (I built many other snapshots too! Each build takes around 15 minutes on a Pi2).
I simply replaced distro files with the built versions so didn't mess with systemd except to disable for CLI tests.

Later...

Well, I did report this issue on the owfs developer's list and after some very helpful discussion, and a bit of work here, a fix was provided.

In summary, there were changes between owfs-2.9p3 and owfs-2.9p5 that affected the way OWNet.pm worked with the server - it turned out that only perl was affected, CLI commands worked correctly.

If a 1-wire server is running owfs-2.9p5 or later and you wish to communicate with it using OWNet.pm then instances of OWNet.pm on the server as well as machines that communicate with it using OWNet.pm should have older versions of this module replaced with the newer version from the current git master. To put it another way, if you issue
set LCD line20.0 test
and your display shows
est||
then you need the latest OWNet.pm. Note that you may have multiple instances of this file.

Further testing has shown that the line20.ALL command was also broken. This is now fixed in the latest git version and git snapshot.

More later..
A post on the owfs-developers list gives details on how to install owfs-3.1p1 packages in raspbian without having to build from source.
Note that this will install the current release version owfs-3.1p1 but will not contain any of the subsequent additions or bugfixes from latest git.

This is the relevant quote from Jan Kandziora..

BY THE WAY, why are you compiling yourself? Raspbian packages of owfs-3.1p1 are available.

Edit (or create) your /etc/apt/preferences to contain:
--------------------------------------------------------------------------
Package: *
Pin: release o=Raspbian,a=stable
Pin-Priority: 500

Package: *
Pin: release o=Raspbian,a=testing
Pin-Priority: 300
--------------------------------------------------------------------------
This is important so you keep stable (Jessie) for all packages but the ones explicitly taken from testing (Stretch).


Then, add a line
--------------------------------------------------------------------------
deb http://mirrordirector.raspbian.org/raspbian/ testing main contrib non-free rpi
--------------------------------------------------------------------------
to your /etc/apt/sources.list to get access to the Raspbian testing repository.

Do an

$ sudo apt-get update

to read the package metadata, then check

$ sudo apt-cache policy

whether the testing repo is there with priority 300. Then

$ sudo apt-get update -t testing owserver ow-shell

Not specifically related to fhem but I finally got around to updating my old Wolfson Pi B running mpd with instructions and kernel provide by hias - (many thanks for the work he has put into this, see the element14 cirrus pages) so it is now running raspbian jessie and cirrus kernel 4.1.19. It was nowhere near as daunting as I expected although I did do a trial run on a backup first - and it seems to sound better now too :)

June 2016

It's the beginning of June and I am indoors with the heating on, hiding from the rain and sudden cold weather outside!

Looking idly through the fhem forum and commandref I came across the 77_UWZ.pm Weather Warning module.
This is designed to fetch weather warnings for German and Austrian users from www.unwetterzentrale.de.

There is a similar, related UK site http://www.severe-weather-centre.co.uk and this module can also be used for UK weather warnings.

Later:
I have been playing with this module for a few days now and I have it working for UK alerts with only a few minor modifications.
I have successfully received several orange thunderstorm alerts in the last two days (see above right image, my scaling has made it almost unreadable).

These mods have now been incorporated in the official module, see commandref for details. Setup details here.

August 2016

I have a had a few PiHut branded 7 port powered USB hubs for a number of years and they have been very useful and reliable but I seem to have come across issues involving two separate devices.

One sits within my fhem setup and connects a number of devices. It is powered by a take-off from my 8A PSU (so power should not be an issue).
One of my USB devices disappeared from fhem so I removed it and plugged it into another port. All has been well since.
There could be a number of reasons for this and may be nothing to do with the hub of course.

Another hub has been with my Wolfson Pi running mpd. This system has been serving me music for years now. It is powered with the PiHut supplied 2A PSU.
The Pi is an original B with original Wolfson card and a Seagate Expansion portable drive.
A while back it refused to reboot. I swapped HDD power to a different port and all was well - for a while. I had to do the same again some time later.

I recently updated this machine and loaded hias' latest kernel.
Following this the Pi would not boot at all unless switched off then on again (bad practice I know).
I tried swapping ports, adding delays to the boot commands, all to no avail. I seem to have mislaid any spare similar PSUs so cannot try a replacement.

Replacing the PiHut port with a ModMyPi naked USB hub has got everything running as it used to.

None of this is intended as any criticism of the PiHut devices, simply my observations. They have served me well and I would not hesitate to buy more of these should I need.
I cannot say the the devices have actually failed and I have not done any testing or further investigation whatsoever.
Perhaps in the second case the startup power required by the Seagate is a factor.

This morning I have had a series of mails reporting dead batteries in some of my MAX devices. This usually signifies that the Cube has forgotten everything - second time this has happened within a couple of months.

Time to dig out my RFBee and Sparkfun USB XBee Exlorer. (I think I chose the Sparkfun adapter as it was cheaper than the RFBee version. All we require is that the serial connections that are brought out to the right pins on the left hand side of the RFBee.)

Programming/flashing the RFBee is relatively simple following the instructions on this page but it may be useful to build the current CULFW version as linked from here.
CD into the RFBee directory then make program should be all that's needed but do check/adjust the serial port in the Makefile.

Connect the RFBee to fhem
define CUL0 CUL /dev/ttyUSB2@9600 1234
attr CUL0 rfmode MAX
and the rest will hopefully be as described in this fhem wiki.

On restarting fhem a new device will be autocreated
define CULMAX0 CUL_MAX 123456

As I write this is as far as I have got. I am waiting for alias definitions to be created before removing the Cube and any unwanted existing definitions.
I haven't had to re-pair the reported dead battery devices, they all came back when I reconnected the Cube after using its USB lead for initial connection of the RFBee.
I am seeing a few errors of the form
2016.08.12 16:46:34 2: MAX_Parse: Don't know how to interpret Ack payload for
I believe this is the RFBee not knowing what to do yet with the signals it is receiving as it has no devices associated with it. Time will tell!

I intend to observe for a day or so, prod a few devices occasionally, and see what happens, if any new devices or aliases appear.

Well, a day later and nothing has changed!

Rereading the wiki the first part explains how to set up the system with a Cube before switching to a CUL to create all devices. I have those so should have ignored it!
This morning I have removed power to the Cube, restored all devices to factory settings and paired each to the CUL_MAX.
All looks reasonably good except for one window switch that will not pair. I have no idea why.

I have tried to pair the working switches with rad stats but the pairing seems to be grabbed by the RFBee. I am sure that way worked OK with the Cube.
The method suggested in the wiki of associating the devices in both directions does work - except for that one difficult window switch.

My Eco switch has to be changed in line with the wiki (it doesn't work in the same way as with a Cube) and I suspect some fine tuning will be needed with that.

The wiki advises against setting up plots before a changeover. Leaving them running has not affected mine in any way.
All device definitions remain substantially the same, IODev and related entries changed from ml to CULMAX0 in my case along with the IODev attribute.

Apart from the one window switch all seems to have gone very smoothly. All I need to do now is restore my weekProfiles as they have all reverted to factory settings.

I was sure I had a spare window switch somewhere and I eventually managed to find it. A new device autocreated and it paired straight away. I guess the other one died.

September 2016

The middle of the month brought some really hot days followed by the usual thunder storm - this one appeared to pass very close by.
Suddenly my internet access and all network devices disappeared!

After a lot of checking it seems that my Alix based Smallwall firewall, Gigaset S685IP base station, an 8 port network switch/hub, a USB hub and a (POTS) phone splitter had all been taken out, completely dead.
My guess is that the local telephone lines must have taken a hit (they are mostly overhead around here). Our local mainline rail service was also disrupted, presumably due to a similar issue.

I have a spare Alix and managed to get the firewall up and running. Fortunately the Vigor 120 ADSL modem/router survived so I got internet access up again too.
My local Currys had a router, at Currys' prices of course, so almost back to normal but it took some time and I have lost a lot of the day's fhem logging for anything network related.

I still have to order a new base station for my Gigaset handsets, sadly it doesn't appear as though they have anything IPv6 available still.

All in all quite a frustrating and expensive episode!

Below shows some of the damage (click images to see larger).
The vaporised track in the phone splitter can be clearly seen in the left hand image.
The right hand image is a bit more difficult to make out but there are signs of arcing and deposits to components to the left of the phone jack in the SP685IP base station.

I cannot see any visible signs of damage to the Alix board or the 8 port hub but they are both definitely very dead.

January 2017

Little to report at the start of 2017, all seems to be working well so far this winter but I have had to change the batteries on my HomeMatic weather station, the originals (Gassner) died but had been working since November 2013.

Longer term considerations

Installing and running your own control system may create other issues...
Consider what will happen if you are away from your system. Will others be able to use it, adjusting if necessary, or even fix it if it all goes wrong?
What will happen when the various parts of the system such as boiler and pump require servicing or replacing? Will your service engineer be able to understand your system and be able to do his job?
What control system will you be leaving when the time comes to move or sell? Will it be relatively easy to transfer ownership of the new system or convert to something that a new owner/occupier can use?

My system to date

Web links