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:
I am updating various parts of this document as I learn more so I apologise if it seems rather disjointed
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 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.
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.
Note: The Conrad HomeExpert accessories page has more adaptors. The eQ-3 MAX! Cube LAN Gateway pages list some. The Pegler Terrier i30 and i35 are made by ELV/eQ-3 (there are similarities between the Terrier and eQ-3 heads but they are not identical in specification as far as I know), the literature is comprehensive and lists many suitable common UK TRV bodies which will presumably apply to the eQ-3 and other replacements.
I have just found an ELV document that lists compatibility and appropriate adaptors for many valves.
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
The following are on order from Conrad Electronics:
Notes: I have chosen these particular TRV heads as they provide temperature feedback, so the system will not require additional temperature sensors. The MAX! Cube provides an interface to all other MAX! components through which one can change settings on the individual components. (Once such settings are made it does not matter if the Cube is offline or otherwise unavailable, the valves will act according to their programmed settings. The Eco Switch, however, will not work without the Cube being available.)
The window sensor is not strictly necessary as the heads will detect any sudden drop in temperature and automatically close down. However using a sensor will provide a more rapid response and increase efficiency, particularly useful in a bath/shower room situation.
The switching actuator is one that provides feedback so I can be sure that a signal has not failed in some way. This may not be particularly important with my current simple system but I hope to upgrade to a fully pumped and controlled system some time in the future. Controlling demand-only firing of the boiler will be one of the first things to overcome - I am hoping that it will communicate with the Cube - we'll see.
HomeMatic and eQ-3 equipment both use proprietary protocols, but most of their devices are supported by fhem. The eQ-3 MAX! System appears to be quite new to the market. I hope I've made a wise choice - time will tell I suppose.
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.
NB. rpi-update or other updates that affect the boot directory on a system running from hard drive may not update the files on the SD card! This will have to be done manually, either by copying the HD boot files to SD card in a card reader or after mounting the SD card on the RPi (eg. mount -t vfat /dev/mmcblk0p1 /mnt ). Any copied cmdline.txt on the SD card will need to be modified to point to the root partition on the HD.
Note that rpi-update is not recommended practice unless required for a specific bug/hardware fix.
The image below is of the fhem web interface showing
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.
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
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.
NB. The eQ-3 and ELV variants of the Cube use different applications and firmware.
Using the wrong application/firmware update (ie. eQ-3 to update ELV or ELV to update eQ-3) may involve having to return to base for re-flashing.
That's all done.
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
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.
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
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
A room used at irregular times may require something
completely different, perhaps a more comfortable
setback temperature for most of the day.
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
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
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.
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 have acquired another cheap set of HE830S.
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 have been looking again at the HE330S modules and
have changed my opinion on them.
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
Temperature (-19.9° to 79.9°)
Relative Humidity (1% rH to 99% rH)
Brightness (arbitrary scale 0 to 255)
Sunshine duration (wrap-around counter, adjustable threshold)
Raining (yes or no)
Rainfall (0 to 999 mm, wrap-around counter)
Wind speed (0 to 200 km/hr)
Wind direction (0° to 355°)
Wind direction fluctuation (maximum 67°)
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 plot for the last seven days
The station sends data very two to three minutes, this generates large logs.
2013-11-30_10:34:48 WeatherStation T: 5.7 H: 89 W: 6.1 R: 2.065 IR: 0 WD: 65 WDR: 67.5 S: 62 B: 11 D: 4.0
2013-11-30_10:34:48 WeatherStation temperature: 5.7
2013-11-30_10:34:48 WeatherStation humidity: 89
2013-11-30_10:34:48 WeatherStation windSpeed: 6.1
2013-11-30_10:34:48 WeatherStation windDirection: 65
2013-11-30_10:34:48 WeatherStation windDirRange: 67.5
2013-11-30_10:34:48 WeatherStation rain: 2.065
2013-11-30_10:34:48 WeatherStation isRaining: 0
2013-11-30_10:34:48 WeatherStation sunshine: 62
2013-11-30_10:34:48 WeatherStation brightness: 11
2013-11-30_10:34:48 WeatherStation dewpoint: 4.0
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).
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
I have purchased a few more HomeEasy devices from
UKAutomation, wall switch, internal and external PIRs.
All are recognised and working with fhem and
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.
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.
Another issue a few days later!
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.
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
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.
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
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.
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.
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.
Net searches seem to indicate that the Cube gets its time from 18.104.22.168, 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.
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.
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.
All now assembled and they look quite reasonable, will soon see if they work too!
I have also ordered another Raspberry Pi from
hopefully arriving in the next few days.
Something has reset the Cube time, it's 60 minutes
The new Raspberry Pi arrived, I installed Raspbian
and a few other bits including owserver and i2c-tools and added the Sheepwalk
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.
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.
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
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
smartphones can cut heating bills by a quarter, (no
idea how long that link will remain).
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.
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.
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 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.
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.
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...
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.
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
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.
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
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.
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.
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!
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.
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 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..
2014.02.20 13:59:58 1: MAXLAN_ExpectAnswer: Error while waiting for answer L:
2014.02.20 13:59:58 1: MAXLAN_ReadSingleResponse: timeout while reading from socket, disconnecting
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.
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.
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.
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
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
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.
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
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!
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 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.
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.
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.
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
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.
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.
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.
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.
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).
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
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
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.
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
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 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.
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 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
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
Raspberry Pi Model B
Sheepwalk Electronics RPI3 I2C 1-wire interface along with a number of attached 1-wire devices
Pi Hut 7 port USB hub
2 no. USB hard drives 8 port LAN router
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
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
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.
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..
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+.
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.
I decided to re-use the now redundant B by adding a
standard RaspberryPi camera.
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!
I have set up LCDproc to talk to the Piface CAD , displaying system stats.
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
... 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.
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.
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.
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.
I haven't added any images for a long time so here
are a few...
A readingsgroup enables the display of a collection of readings from one or more devices.
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.
Image of the page I created for controlling my heating system.
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.
HourCounter plot displaying my boiler and pump switching.
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.
More complex plot displaying current settings of all my MAX valves.
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.
Another logProxy plot showing a single MAX valve and weather data.
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
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.
That's all for 2014, hoping 2015 is a good year for all.
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 tried many things with no luck so I removed a
couple of rad stats and reset them, then paired to the
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
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 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.
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.
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.
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+.
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
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
Waste collection visualisation.
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
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
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.
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
for any issues.
Some time ago the update method changed slightly although the
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
In order to revert the latest update on my system I would enter
followed by the usual
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). I have other browsers available but
choose to use them for different purposes.
(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).
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...
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 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.
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.
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
Are their systems really so bad that it takes around
six hours to tell me that there was a problem with my
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.
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 received my order the following day with help from
the supplier Label King.
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...
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...
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.
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...
The answer is to add an alias to the calculated
entity and use the alias for formatting.
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
pi:~$ sudo uptime
08:20:02 up 138 days, 5:19, 1 user, load average: 1.09, 1.09, 1.13
cubie:~$ sudo uptime
08:20:30 up 43 days, 18:00, 1 user, load average: 0.14, 0.19, 0.16
Autumn and the heating season is here again!
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.
I have acquired a UPS, an
APC Smart-UPS 750, SUA750I (sine wave output not
the more usual stepped sine wave).
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
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
Vaguely related to the above, I am considering
moving fhem back to a Pi - or more specifically a
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.
Some things for me to play with through the winter :)
fhem is now at version 5.7 and there are some notable changes particularly regarding the notify command.
Major changes are that..
@, % , %NAME , and %EVENT are no longer permitted and
should be replaced with $NAME and $EVENT .
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.
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.
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 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.
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.
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 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
Unfortunately it is not working as expected on my
jessie Pi2 with its Sheepwalk Electronics RPI3 1-wire
I set up another Pi2 with my old 26 pin RPI3 to
check this out.
Installing the 2.8p15 1-wire debs on jessie after
removing the jessie versions corrects the behaviour in
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).
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
Further testing has shown that the line20.ALL command was also broken. This is now fixed in the latest git version and git snapshot.
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 :)
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
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.
East of England and UK Weather Warning images
These mods have now been incorporated in the official module, see commandref for details. Setup details here.
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).
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.
I recently updated this machine and loaded hias'
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.
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.
Connect the RFBee to fhem
On restarting fhem a new device will be
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
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
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.
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.
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.
The middle of the month brought some really hot days
followed by the usual thunder storm - this one appeared
to pass very close by.
After a lot of checking it seems that my Alix based
base station, an 8 port network switch/hub, a USB hub
and a (POTS) phone splitter had all been taken out,
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
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
I cannot see any visible signs of damage to the Alix board or the 8 port hub but they are both definitely very dead.
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...
My system to date
Last updated 20-01-2017
All trademarks referred to in this web site are the properties of their respective owners. Trademarked names appear throughout the content of this site. Trademarks, and their respective owners, are not systematically listed or marked in the text, but nevertheless all trademarks are acknowledged. Any trademarks or names being used are for editorial purposes only, and to the benefit of the trademark owner, with no intention of infringing upon that trademark.