Discover the Flukso in your LAN

by gonium on

For the mySmartGrid project I will use a Chumby as a device for showing the resource consumption, in addition to providing other features. Since I will roll this out in up to 1000 households configuration needs to be automatic. The problem is: how does a Chumby (or any other device) locate the Flukso in the local LAN? Turns out that Zeroconf is a neat solution to this. I use http://www.avahi.org for this.

First, you need to install the avahi daemon on the Flukso. This is easy since OpenWRT provides a package for it:

  1. $ opkg install avahi-daemon
  2. $ cd /etc/avahi/services
  3. $ cp ssh.service flukso.service

Then, you edit flukso.service to your liking. I assume here that a TCP daemon listens on port 4422:
  1. <?xml version="1.0" standalone='no'?><!--*-nxml-*-->
  2. <!DOCTYPE service-group SYSTEM "avahi-service.dtd">
  3. <service-group>
  4.  <name replace-wildcards="yes">Flukso on %h</name>
  5.   <service>
  6.    <type>_flukso-realtime._tcp</type>
  7.    <port>4422</port>
  8.   </service>
  9. </service-group>

After starting the avahi-daemon you should be able to find the IP address and port number using any Zeroconf/Bonjour/Avahi client. On Mac OS I use the Bonjour Browser.

But I also wanted to write a small C program that just gives me the location of the Flukso. First, I installed a minimal version of the Avahi libraries on my Debian ARM NAS device:

  1. $ ./configure --disable-glib --disable-gobject --disable-qt3 --disable-qt4 \\
  2. --disable-gtk --disable-dbus --disable-gdbm --disable-python \\
  3. --disable-mono
  4. $ make

Afterwards, I modified one of the example programs to print the IP and port of the "_flukso-realtime._tcp" service type. You can find a small tarball of the code attached. CORRECTION: I am not allowed to upload a tarball :-( The tarball is here:

http://gonium.net/media/flukso-discover-0.1.tar.bz2

It works on my ARM-Debian machine and on an x86 Mac OS (Snow Leopard), please adjust the simple Makefile to your installation. This is how the output looks like:

  1. $ ./flukso-discover
  2. Joining mDNS multicast group on interface en0.IPv6 with address fe80::216:cbff:feaa:a726.
  3. New relevant interface en0.IPv6 for mDNS.
  4. Joining mDNS multicast group on interface en0.IPv4 with address 192.168.1.100.
  5. New relevant interface en0.IPv4 for mDNS.
  6. Network interface enumeration completed.
  7. (Resolver) Service 'Flukso on flukso' of type '_flukso-realtime._tcp' in domain 'local':
  8.         192.168.1.101:4422 (flukso.local)
  9. Leaving mDNS multicast group on interface en0.IPv6 with address fe80::216:cbff:feaa:a726.
  10. Leaving mDNS multicast group on interface en0.IPv4 with address 192.168.1.100.

I haven't figured out how to suppress the log messages, but this works for me.

Bart: What are the chances to integrate a realtime reading server in your lua code, instead of broadcasting realtime values? I will not investigate this today, but for mySmartGrid I have the following plan in my mind:

  1. Discover where the Flukso realtime service is, see above.
  2. Open a TCP connection and retrieve the current reading.
  3. Repeat the last step as often as needed.
‹ [bug] Lua scripts returns occasionally impossible high consumptions [bug] wpa session does not recover from disconnection ›
icarus75's picture
icarus75 |

Hi Mathias,

Having a Zeroconf/Bonjour/Avahi daemon on the Fluksometer for LAN service discovery looks like a sweet solution to me. The Fluksometer could advertise its service(s) to a slew of devices connected to the LAN like a Chumby, laptop or smartphone. As for the power readings, the Fluksometer's avahi daemon could announce a UDP real-time power service with a control port on e.g. UDP:4422. Every device interested in this service then sends a subscription message to port 4422 on the Fluksometer. The Flukso daemon will send power reading messages in 1sec intervals to each device:port entry in its subscription table. Subscriptions will have a 5min time-out, forcing each device to send a subscription renewal within the time-out period to enjoy uninterrupted service.

Thoughts, comments? Shoot!

Cheers,
Bart.

gonium's picture
gonium |

Hi Bart,

to keep it short: sounds good! A subscription message should specify the desired IP and UDP port where the readings should be sent to. So, my Chumby would discover the Flukso, then send an UDP packet to the Flukso (UDP port 4422). The packet can be encoded in JSON, for example.

Afterwards the Chumby listens on the designated UDP port for the high-frequency readings. These should also be encoded in JSON for simple interpretation. The Flukso could send something like -tuples for all sensor id's its responsible for.

Cheers,
-Mathias

mservaes's picture
mservaes |

If I do the first command, as written down in these instructions, I get an error...

An error ocurred, return value: 716563936.

I am doing this in the command-shell of the Flukso device... is this correct ?

gonium's picture
gonium |

Hi mservaes,

yes, you have to SSH into the Flukso. Typically, this error occurs if your local package list is out of date. Don't ask me why opkg doesn't tell you so directly. Try

  1. opkg update

to update the package list.

Just my 2ct,
-Mathias

mservaes's picture
mservaes |

Yup, that seems to be the trick... I now know what to do further...
Thanks.