Chef de Cambuse, cruising and wine

Entries in the Category “EIB”

Fixtures for the next weeks

written by Frank, on Oct 19, 2010 12:40:00 PM.

Some news from this side if my life.

I’ll be at the Samsung Smart TV Developer Day 2010 this week in Frankfurt.

Next week I’ve the pleasure to host a BoF named “Android and Its Impact On Home Entertainment and Home Automation” at this years CELF Embedded Linux Conference Europe in Cambridge, UK.

Returning from ELC-E I will head straight to elektro:camp(<<2010>>).

A barcamp in Kaiserslautern about

  • Smart Metering
  • Home Automation
  • Home Displays
  • …and much more.
It is the first of its kind and I’m really looking forward to this to learn more about and see what the folks from Flukso are coming up with.

And last but not least I’ll be in Munich on November 9th for the Google Developer Day 2010.

there will be light

written by Frank, on Mar 16, 2008 12:35:00 PM.

Over the last days I’ve added support for the UPnP Lighting Controls V 1.0 to Coherence.

Although there aren’t yet much application areas for this specification outside of maybe some futuristic showrooms and research laboratories - and here at my place with my little UPnP <-> EIB bridge - but that specification addresses one of the biggest obstacles when it comes to home-automation.

The need to know/to program the unique id of a new device you bring into your household and to establish the connection between a switch and that device, is in all serious automation systems diametrically opposed to the wish of the ordinary customer who just wants to buy a new lamp, plug it in and have it working.

Newer systems like digitalstrom or ZigBee take that (partially) into account, but here too UPnP has the potential to model a unified layer above the system and vendor specific peculiarities.

And having that in Coherence is a nice demonstration of the simplicity implementing a device with it anyway.

class SimpleLight(Backend):

    """ this is a backend for a simple light
        that only can be switched on or off

        therefore we need to inform Coherence
        about the state, and a method to change it

        everything else is done by Coherence

    implements = ['BinaryLight']
    logCategory = 'simple_light'

    def __init__(self, server, **kwargs): = kwargs.get('name','SimpleLight')
        self.server = server
        self.state = 0 # we start switched off
        louie.send('Coherence.UPnP.Backend.init_completed', None, backend=self)

    def upnp_init(self):
        if self.server:
            self.server.switch_power_server.set_variable(0, 'Target', self.state)
            self.server.switch_power_server.set_variable(0, 'Status', self.state)

    def upnp_SetTarget(self,**kwargs):'upnp_SetTarget %r', kwargs)
        self.state = int(kwargs['NewTargetValue'])
        if self.server:
            self.server.switch_power_server.set_variable(0, 'Target', self.state)
            self.server.switch_power_server.set_variable(0, 'Status', self.state)
        print "we have been switched to state", self.state
        return {}
Yep, that’s all. :-)

From the three UPnP actions the SwitchPower service defines, only one is actually needed to implement, the other two actions can be handled by Coherence autonomously.

EIB time-signals

written by Frank, on Apr 27, 2006 1:27:00 PM.

Quite some EIB devices have time-controlled actions nowadays, for example the GIRA Tastsensor 2plus. But apparently their internal clock has its own interpretation of time and seems to lose any contact with reality shortly.

One way to get around this is to use an EIB time emitter, something with a buildin DCF77 receiver, cyclically sending a time telegram on the bus.

On the other hand, with our eibcontrol homeserver and a simple NTP setup, we can achieve the same with just a few lines of code.

We need to add a dummy group address to the homeserver’s xml-database, something like this:

<node name="0" alias="central functions">
    <node name="0">
        <node name="40" alias="timer">
            <node name="valuelength">3</node>
            <node name="eistype">3</node>
            <node name="curvalue">0</node>

Now armed with some knowledge about the time encoding in an EIS 3 type (p.15) writing a little (Python) script that, when invoked, sends the current time to the above defined group address isn’t a big deal anymore.

# _example_(!) python program for eibcontrol communication
# (c) 2006 Frank Scholz, dev * netzflocken . de
# -a 0/0/40 

import socket,string,time,struct

HomeServer        =       ''
HomeServerPort    =       8081 
EIBaddress        =       (0,0,40)

write_request = """<eib type="write" path="/eib/groups/%d/%d/%d/curvalue" data="%ld"/>\n"""

def eib_set( server, port, address, value):
    s=socket.socket( socket.AF_INET, socket.SOCK_STREAM)
    s.connect( (server, port))
    request = write_request % ( address[0], address[1], address[2], value)
    s.send( request)
    result = s.recv( 1024)

    if( string.find( result, "state=\"true\"") != -1):
        result=result[ string.find( result, "data=\"")+6:]
        state=result[ 0 : string.find( result, "\"")]

    return( state)

def eis3_build( day, hour, minute, second):
    r = day<<21|hour<<16|minute<<8|second
    return struct.unpack("L", struct.pack("!L", r))[0]>>8

t = time.localtime(time.time())
value = eis3_build( t[6]+1, t[3], t[4], t[5])
eib_set( HomeServer, HomeServerPort, EIBaddress, value)

Download: a slightly longer version with parameter handling

Now put this in a crontab and you are all set.

Currently the eibcontrol homeserver whinges about not receiving an ack from the bus for his “write”-request. As there is no “send-only”-request we need to simulate this for now and live with the otherwise effectless nagging.

progress with the new html SimpleVisu

written by Frank, on Dec 14, 2005 10:43:00 PM.

Visu-alpha-20051214More than a year after I started with the simple html based visualisation of our home-automation system I finally found some time to reimplement it.

But now based on the uebercool, all singing and dancing Ajax technology.
The picture is probably boring as I havn’t really worked on the widgets yet, but I tried to resemble the visu I’ve done in 2004.
Most of the interesting things are under the hood:

  • nearly everything is Javascript generated, meaning on loading of the page only some Javascript is bootstrapped which then requests the visualisation objects and generates the html code
  • CSS based, layout and appearance can easily be customised
  • no page reloads, all communications with the server part are made with XMLHttpRequest
  • better separation of presentation and application layer, despite the initial html/javascript bootstrap only events (e.g. object xyz has changed its value to n) are exchanged between the visu app in the browser and the server part
  • and in the end the best: EIB events are processed in realtime, a press of a sensor button immediately changes the representation of its object(s) in the browser