Server reboot

After 465 days, or one leap year and 99 days, the home automation server rebooted!

 

Not that it wasn't going strong, just the painter/handyman that came around to fix some things disconnected the power, causing the reboot!

 

I still find it impressive that it ran so long with no issues.

 

However, upon the reboot a few problems came to light, mainly due to my lack of knowledge and of proper planning.

 

The little executables that I have written to listen to the arduino that reads the meters, and the JeeLink that a talks to the boiler did not get started upon rebooting of the server, which is not ideal, considering the winter is here to stay. To make matters worse, this happened on a Tuesday, and on Wednesday I was traveling to Berlin for work. If he did it again during my absence, it would not be nice for the rest of the family.

So first, when I got home, I restarted the whole stuff, so that the house would come back to a decent temperature. This already revealed a little bit of the problem, which is that a certain device not always gets the same device driver in Linux. So that was the first problem to tackle, quickly solved with some rules in udev to create an aptly named file under /dev based on the serial number of the device. Only possibility, since both the arduino and the JeeLink both share the same identification information.

Next was to start these executables automatically. I had tried before to put them in init.d, but that had not worked. So, after many reboots to try different configurations, I finally found out that, since my programs are not properly written to be daemons, they never return, and then init.d does not launch them.

The solution came with 'startproc' which launches any executable as a daemon! Put that in the corresponding init.d configuration file and off it goes!

Another reboot to check that all is well, and time to bed!

Did not receive any complaints while in Berlin, so all was good!

I really should use better technologies to get these things going, but I always find that once it is working, it is difficult to motivate myself to improve it! I always move quickly onwards to the next problem...

As a further note, this server, a mini-itx board, has been running the house for 5 years now! I ordered a raspberry-pi to replace it, just due to the power consumption. I now have around 25W, and I hope the Pi will do with at most 10W!

Dashboard once again

It's been more than a year since I last published about the dashboard. And that it because not much happened in that front.

Meanwhile, a friend gave me a tablet, cheap chinese thing, which I planned to use to display the dashboard in a visible place in the house.
The thing could even display the HTML5 and handle the AJAX calls and all, but it was unstable, sleep mode would spend the battery almost as fast as normal mode, slow to boot, bad touchscreen (resistive), and so on, and so on, so I quit on it, and consequently on the progress on the dashboard, as the experience while using it is, in my opinion, of great importance!

A few months later, my wife offered me an iPad, the new retina display model! so that rekindled my interest in the dashboard. I came back to iWeb, expanded the design a bit, and have spend a couple of evenings implementing the functionality...this is the result:

And for the explanation:

electricity and gas consumption: the pointers move, as the data is updated, and shake slightly when stable, to indicate that the thing is alive. The numbers are updated twice a minute.

House control: this interfaces mainly with the FHZ1000 part of the automation. It reads set, measure and desired temperatures, displays the measured, and makes the box green if the room is set for comfort temperature (even if it has not yet been reached) and blue for low temperature. The boxes turn orange is there is no reply.
The buttons for the awnings are toggle buttons: click to extend them and click to retract them, since the system has no idea of what their status is (they can be operated locally). They briefly blink through orange to give feedback that something happened!
climate limited: is a button to limit the maximum temperature to which any room can be set
holiday mode: should set all rooms to a low temperature and out of the standard program. this is the only button not yet functional (and therefore transparent).

Door events: list of the last 4 events on the RFID door.

System messages: reports errors on the system, like now, the weather station has stopped transmitting.

Agendas: list a few items (enough to fill the respective boxes) taken from google calendar. I have a google calendar for the house, where I put the garbage schedule, and other maintenance activities that need to take place.

Outside temperature: like the name says, displays the data from the weather station. Now it displays nothing, since the station stopped working - see system messages :)

And that is it! data is updated on timers, and the agendas on loading of the page.

There has been talk in the tubes about some mechanisms to update data in real-time. That should be the next development, but that might take another few years :) This is nice enough to show to my friends :)

AH! last but not the least, I found out that one can include some lines in an HTML page to make it a iPad app, so, by adding:

    <meta name="apple-mobile-web-app-capable" content="yes" />
    <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" />

I can save the page onto the iPad desktop (is it what it is called?) and run it as any other app, without the safari address bar. Only the top bar with the clock and stuff is still visible, but that is even a plus, as it gives you a clock and iPad info!

I'll try to post a screenshot from the iPad soon!

Switch Box

This weekend I finally finished a project that has been on my mind for quite some time: a Switch box!

In a few words, it is a box of electrical plugs, each with its own switch.

A few months ago we changed our old CRT TV by a new flat modern HD thing, mainly to get rid of the annoying little decoder box that we were forced to use in order to see the channels that we liked that were moved from analog to digital, and, since we every night switch off all devices, in the hardware switch we made sure the new TV had such a hardware switch.
So when we come home, all happy with the new TV, and switch, we discover that the nice sound bar that came with the TV not only required a separate power supply (plug) but didn't have a real switch, that allied to some devices hanging around that did not have a hardware switch (DVD player) which required a unplug action, until I hacked a light switch on to the cable, I decided to make the following contraption.

 Under side

 Top side

It is a series of 6 plugs, just like an extension cord, but where each individual plug has its own switch, UK style. I then hid it under the furniture where the TV and all devices rest on, with the plugs nicely hidden under it.
I think these things should be sold in shops! As a side note, I did consider having a remote control for this, using a micro-controller and some SSRs,  but that would complicate it, both in terms of build time, and safety considerations.
I am also not sure I it will ever recover its cost in saved energy, but hey, if we account for the energy I save going around unplugging devices at the plug, it already payed it self off today!

I hope you can get a good idea of the result from the pictures!

 

Mounted in place

Another view of it in place

JeeTherm update

Back to electronics, here are some news of the JeeTherm, as, since the cold season is about to start, it is time to do some tweaking.

It has been working fine since I last touched it, back in January, just before a big cold spell around here! but there were a few little issues, namely:

1: The reported values were the last values read from the boiler, however, if for example the hot water was used briefly, I would see an increase in temperatures, but no indication that the burner had been used. This was easily solved by reporting the maximum value of the status that occurred between radio messages.

2: (and this one was trickier) sometimes the daemon running on the server would stop reporting serial messages from the JeeLink. After spending a lot of time improving the serial and socket handling (written in C) and not getting better results, I gave up for a while. The system still worked, as the calculated temperature was still sent via serial and subsequently via radio to the JeeTherm, only I would get no reporting back. Eventually, the solution I found was to automatically restart the serial port if no message would be received, via serial, for more that 2 minutes. The strange thing was that the serial to the JeeLink and radio was still working, so I thought it could be some sort of air waves conflict. However, since there is a sequence number on my radio message, which is increased even if the communication fails, I would have expected to have larger numbers when communication failed, due to the retrials. But this was not the case, all numbers could be accounted for in the minutes that were missing. So the radio message was coming across, being received at the JeeLink, only not making its way into the serial port.
Just as I was re-flashing the JeeTherm, I googled a bit on the subject and found some reports which led me to think that radio noise on the line, from the FHZ1000PC on another USB port could be disrupting something. Changed the JeeLink to a different USB port, and it appears to have improved...time will tell.

3: The JeeTherm reported every 60 seconds, but, since I have no synchronization, a aliasing phenomenon was occurring. I explain. The setpoint calculation is made once a minute, on the minute, on the server, and sent to the JeeLink, where it waits for a message from the JeeTherm, to reply with the new setpoint. Due to the aliasing, sometimes the radio message came in just before the new setpoint calculation, so I wold be running the boiler with a 1 minute delay from the calculation. Not very serious, but not how things are meant to be :)
So, the solution was to report, in the reply from the JeeLink to the JeeTherm, via the radio,, the age of the data, in seconds. So I measure the seconds since a new setpoint was received at the JeeLink and send this back to the JeeTherm. The JeeTherm then uses this age to adjust its reporting interval in order to always have the freshest data. True enough, after the first radio message, which happens whenever I first turn on the JeeTherm, all other messages come in 5 or 6 seconds after the minute (the 5 seconds delay is on purpose, to allow some leeway, it could be anything)! now I have a basic synchronization implemented!

The code for all this will soon be on Github

Soon, more on the self powered OpenTherm interface, and other Jee's!

CarolTop

It's been a while since the last post! But I've been busy nevertheless! With electronics, as usual, but also with a completely different kind of thing: sewing!

Last year we got a new camper van, with a popup roof. We use it mainly to go to sunny places, but, either in the way, or at the destination, sometimes there is the eventual rain, and that got me concerned, as the tent that pops up is made of cotton, and although waterproof, when it rains it gets wet, and if I need to lower the roof with the cotton wet it is not very handy. Not a big problem if you are in a warm place for a few days, as it will dry, but if it keeps on raining...

So, time for a solution. First, a google search revealed that there are a few commercial solutions, which are not more than a plastic enclosure to put over the popping roof to keep it dry. As I almost ordered one of these, the holidays were approaching, and it occurred to me that we have a sewing machine, which I always wanted to learn how to use.

Spent one night getting to know how to run the line through it, and how to get all the different stitches and then I felt I was ready.

Bought a big blue tarpaulin, I think it was 3 meters by 4 meters, layed it over the poped roof, and marked the lines I would have to sew.

The night before we departed I was until 1 in the morning sewing the thing, including some eyelets to tie it down to the car, so no time to check if it fitted well or not. Off we went into one more road trip.

Already in the first week we had an opportunity to use it. The rain was coming, so we placed the CarolTop over the van. It was easy, less than 5 minutes with 2 persons, and it did the job! It fitted, although it needs some adjustments, and it kept us dry.

I now plan to redo it using a lighter weight material, like a tent cloth, and once I do that, and have the right sizes figured out I'll publish it here. Meanwhile, here are some photos, I even made a logo for it!

Needs some adjustments on this side, it is not very tight.

 Here is the logo I made, at 1am.

The eyelets, spread around to allow it to be tied down.

 View from the other side, this side is nice and tight.

 

Laser trip wire

New project! and completely different from the previous ones...although, as usual, it also includes a JeeNode...

So here is the problem to solve: I have a garage, where I have to park a rather large van, that fits in tightly. Once it is properly parked inside, I have 20 or 30 cm of play, divides between the front and the back. So when I park it, I usually do a few iterations of leaving the van to check if the door can already close, get back in, reverse a bit more, check again, and by the time it fits the parking sensors are already beeping that I hit the back a long time ago.
So, to address this problem, I am sure there are plenty of analog solutions, ranging from balls hanging from the ceiling to god knows what, passing by my backup solution: a brick on the floor where the rear wheel hits.
But an analog solution would be no fun, so here is the action movie solution: a laser trip wire.

I wired a laser and a LDR in a small enclosure, and connected all this to a JeeNode, which reads the value of the LDR and turns on and off large red and green LEDs! Place this right at the foremost point where the van is fully inside, and problem solved!

I even thought of reflecting the laser all around the van to make a virtual box where the van would have to fit inside...maybe in the future.

So, I hear you all thinking, this is a bit of overkill, to use a JeeNode for this that would easily be done in analog electronics with a couple of transistors, but here are the advantages of a radio enabled micro controller:

1) I can connect a door sensor to it, and broadcast the status, effectively using it as an alarm.
2) (the truly amazing one) I can send the status (inside/outside) at a high refresh rate over the air, and build me a small receiver to have inside the van giving me an aural and visual warning!

This receiver is not yet there, but it is in the plans...so it is still vaporware...sorry for that, but here are some pictures of the laser trip wire:

 This is the emitter unit that will be located at the foremost point that the van is in and is connected by a cable to the main unit (below) which is located at eye level.

The main unit, with the 2 large LEDs, I have put it in a box, and I'll show some pictures once it is in place. The unit allows for reading a second analog input, which I intend to use to read a pair of limit switches, indicating that the door is open enough for the van not to hit it, and to alarm the house when the door is opened.

Small update!

It has been a while since I posted something here...the truth is, not much has happened in the electronics front.

The JeeTherm has been working flawlessly since I installed it, on the 15th of January, so that it over 2 months ago. During those 2 months, we had some serious cold coming this way, I measured -15C on my weather station! That is the lowest ever recorded here.

One interesting thing about this whole story of the efficiency of an HR boiler, is that, due to some graphics I found I limited the temperature setpoint of the boiler to 55 degrees, as this is the limit above which the efficiency decreases rapidly, thinking that, if it gets really cold, I could raise this limit, as it is all software anyway, and there was no need to recompile anything (on the JeeTherm the limit is 80C, on my PID controller implemented in PHP, the limit is 55C).

As the cold came and settled in, I noticed that the boiler, and the whole heating system was still able to warm up the house, and keep it warm, even in the coldest days! so I ended up never having to raise it! I was glad, I had days where the boiler worked nonstop, but down to a simmer. My energy saving correlation calculation also indicated that the gas spent was way below expectations, although the curve fitting was not done with any data in that kind of cold range.

What bothers me the most, is that I could never really find any good info about this efficiency story. In many forums you can find people saying that an HR boiler needs a 20C difference between feed and return to operate at optimal performance, but all the graphics I find of performance, none indicates such a difference, the efficiency being a simple function of the return temperature. Furthermore, if that is the case, then the boiler should be set to start modulating to try and achieve such a difference, but the behaviour I see with my boiler is that it modulates to have a 7C or 8C difference between feed and return. sometimes even 5C. I start to think that all that matters is the return temperature...and that one, I have it limited to 55C now!

Project finished!

This is it! The OpenTherm JeeNode/Arduino interface is finished! and all ready to roll!

The prototype had been working for almost two months now, and finally the boards arrived from fabrication, I think the result was worth waiting for, and worth doing it! I got three identical boards, so if I mess up one I can go on with the next:

Bare boards

Very simple, but very effective :)
I thien collected the components, whe to buy the optocouplers, and incorrectly bought the 4N35 instead of the 4N27 that the prototype used, but only realised after they were already soldered, so I tested it, and they work fine! crisis averted:

All ready for assembly

Mounted everything, both the JeeTherm, and a JeeNode v4 I had around still to be assembled, and put it all in the enclosure:

Assembled, and in the enclosure, attached to the JeeNode

Another view

Had to fiddle a bit more to get the screen fitting in the cover, and connected to the JeeNode:

All ready for action

Checked that it all worked, and got it connected, instead of the prototype. It is now running happily:

Talking to the boiler

I am quite proud of the final result, it looks good and well packed, and I tried not to cut any corners this time, took my time, and tried to do it patiently...very often I end up messing up things in the rush to get them finished.

It is now in beta test phase, if it works well for the coming days, then I will attach it permanently, now it is still floating :)

Already thinking of the next project!