Group Actions
Engagement
  • Author Author: kipe
  • Date Created: Date Created
  • Views 289 views
  • Likes 0 likes
  • Comments 3 comments
Related
Recommended

Forget Me Not - 3 - Getting over the RF range

kipe

As you may know, I’ve been working on a Python -library for the EnOcean Pi and sensors. At the moment of writing, the library is pretty much working, I just need to do more unit tests before I publish it. This is to allow easier integration of (hopefully many) pull requests.

The basic stuff is supported by the library, receiving data from the sensors, parsing the sensors provided in the kit to human readable form and sending/receiving commands to the TCM 310.

Network based sensor nodes

I’ve been playing around with the idea of multiple Raspberries working together to create a sensor network for those hard to reach places. This would allow extending of the sensors range to whatever your network topology allows. For example, this could be useful in large, multi floor buildings, where a Ethernet cabling already exists. Just put one Pi with EnOcean Pi per floor, connected to one “Master-Pi”, which collects all the data. The idea is shown in the figure below.



image



The “remote” Raspberries would act only as a relay which send the messages to the master. All the data transmitted through the sockets would be exactly the same as the data coming from EnOcean Pi, so the master would do all the parsing. In case the data couldn’t be relayed to the master, the remote should cache it and send later.


This kind of structure (without a custom data-format) would allow the remotes to send data to basically any program (even OpenHAB), as long as there’s the possibility to listen as a socket server.


Of course the “sensor nodes” wouldn’t need to be Raspberries, or even use the EnOcean sensors. They could be anything, maybe a Arduino with Ethernet or WLAN shield, your mobile phone or desktop PC. I’m even thinking about using a Connected Launchpad with Power-Over-Ethernet -mod!

As long as the data format is predefined (as it is with the EnOcean protocol) and the sensor node can connect via TCP/IP, it should be easy to implement. Actually, I’m thinking about using my desktops CPU temperature as a “showcase” for the implementation.


What kind of use cases can you think for this kind of system or do you think this is a waste of my time? I have couple of ideas myself, mainly extending the range of sensors where installing (multiple) repeaters just wouldn’t be practical (and normally they would need power anyways).

  • in reply to electronichamsters

    Actually I read your post too, while I was writing this, it's a very good idea!

    I've been thinking about these local devices gathering info from remotes (that's why the arrows between devices are two-way image). I'll have to look into MQTT too, at first glance it might be just the thing to transfer these messages, instead of pure sockets. With MQTT it would be possible to extend the network quite easily and most of all, reliably...

  • Hello Kimmo,

    I've thought along the same lines in terms of extending the reach of sensors.  I'm using MQTT for a lot for my sensor network.  In fact, my Arduino sensors indirectly report to OpenHAB via MQTT.  For me, rather than being concerned about extending incoming data, I was focused on extending outgoing actions - instead of using multiple RPi's as data relays for incoming sensors, I'm using multiple RPi to perform OpenHAB audio alarming in multiple locations.  The "remote" RPi run pretty much the same OpenHAB application as the master, but the master holds the MQTT server, and the remote RPi subscribe to the master's MQTT server.

     

    MQTT should work across the internet too.  It's designed to be used or simple sensor data.  One of my blog posts gives an example with an apartment complex.

     

    Eric

  • I wound up making a simple test with the Launchpad and can now confirm that everything the EnOcean Pi -module seems to need is 3.3v, ground and serial.

    The pin order is shown on the image below. Note: 3.3v is on the otherside compared to the other pins, double check when connecting!

     

    image