more G-Labs products

Author Topic: New device driver for linux char device  (Read 2435 times)

December 05, 2014, 10:30:49 AM
Read 2435 times

JK

  • *
  • Information
  • Newbie
  • Posts: 3
Hi together,

I am currently setting up an own light controlling system that works via RF with nodes and external switches talking to each other, the whole protocol and setup is expandable to sensors etc.
The main "server" unit is a small Raspberry Pi, with an RF chip attached. The server is supposed to run HomeGenie, because it seems to be a good light-weight choice. I have already written a kernel driver for the module that also includes the send/receive protocol, timing, setting encryption etc. and added the device as a char device to /dev/rf. So the interface is quite simple: The first byte that can be written to the device is an address byte, the subsequent ones data bytes (e.g. for HSV encoded lights) with a fixed length. The same is true for the readout. Everything works fine and is tested via small C/C++ programs and "echo -n, cat".

Now I want to interface it to Homegenie such, that I can add (to start with) an RGB light slider/button for each of the addresses. I thought it might be best to start looking at the ExampleDriver.cs, and at the GPIO implementation for the Raspberry.
But since I never used C#, I mostly come from a C++ (for small Mikrocontroller/Kernel projects C) world, and I am still missing overview of the whole HomeGenie code structure/concept, I wanted to make sure that I don't run into too many dead ends right from the beginning.  I am mostly missing a minimalistic step-by step tutorial/example, how to come from the ExampleDriver (with many addresses) to - lets say - a slider/button for each.

So my question is: Did I chose the right way to start?
Please feel free to redirect me to any thread dealing with similar problems or to any documentation.

Thanks!

December 05, 2014, 01:31:41 PM
Reply #1

Gene

  • *****
  • Information
  • Administrator
  • Posts: 1472
  • Tangible is the future!
    • Yet Another Programmer
There are two ways of doing this:

1) create a MIG interface
There's an example using a file system mapped device such as Raspberry Pi GPIO interface:
https://github.com/genielabs/HomeGenie/blob/master/MigFiles/MIG/Interfaces/EmbeddedSystems/RaspiGPIO.cs
this implement simple operations like on, off and status request.
If you also want real time events you have to add a reader thread like in this other example:
https://github.com/genielabs/HomeGenie/blob/master/MigFiles/MIG/Interfaces/EmbeddedSystems/Weeco4mGPIO.cs#L683
After creating a MIG interface you have to add it to the UI interface settings page, so the user can enable/disable it:
https://github.com/genielabs/HomeGenie/blob/master/BaseFiles/Common/html/pages/configure/interfaces/main.html#L297
and also add an entry in the systemsettings.xml file:
https://github.com/genielabs/HomeGenie/blob/master/BaseFiles/Common/systemconfig.xml#L130
and that's it, everything will be ready to work.

2) creating an Automation Program from HG Automation section
The closest example to what you want to achieve is the app called "One-Wire Devices" that read sensor values from file system.
This app is located in "Configure->Automation->Devices and Things".
This is a C# script, but you could also try Python, Ruby or even Javascript. For documentation look here:
http://www.homegenie.it/docs/automation_getstarted.php
http://www.homegenie.it/docs/hgsdk.html

Cheers,
g.



December 08, 2014, 01:47:09 PM
Reply #2

mrburns42

  • *
  • Information
  • Newbie
  • Posts: 11

Hi JK,

Any chance you can share the details of the radio you are using and the protocol?  I have been looking at several radios.   The HopeRF stuff seems very good.   Are you using something similar?   The ones I looked at were at:

http://lowpowerlab.com/

Thanks.

December 09, 2014, 02:22:14 PM
Reply #3

JK

  • *
  • Information
  • Newbie
  • Posts: 3
Hi,

thank you for the reply, Gene, I will give it a try as soon as I can find some time beneath work. I would probably go for solution 1 with reader thread.

The radio I am using is the HopeRF RFM69CW, which is indeed quite nice, because it does lots of things directly for you (packet handling, AES, crc). When I started digging into it, there weren't too many libraries, and none of them seemed a very good choice, so I just wrote my own, initially thought for small microcontrollers. I then ported it afterwards to a linux driver.
If I got the Monteino thing right, the board includes a small µC. I directly wired the RFM to the raspberry, thats why I really needed a kernel-level driver for the time-critical things. I guess with an additional intermediate buffer it might be possible to avoid this, so probably the Monteino is a good idea.

If you are really interested in my protocol, its extremely simple, has fixed length, and no ACK or anything. I've already described it in my first post, it transmits in bytes: address, data0, … , dataN. In the light application case: address, h, s, v, ctr_byte. The ctr_byte is used to discriminate between packet types. The checksum is handled by the RF module.
 I hope this helps.
Cheers

December 11, 2014, 08:07:43 PM
Reply #4

mrburns42

  • *
  • Information
  • Newbie
  • Posts: 11

Hi JK,

While your protocol may be simple,  I think the HG  C# code that you generate will be useful for other noobs, like myself.   Many us have ideas, but lack an example to port from.    None of the experts in this forum has the time to help noobs generate code from the very first line of code.  However, by studying several other people's projects, it is possible for someone without a lot of experience to at least cut and paste together a test case.  Once they have a test case and can report what worked and what did not work with their actual code to the forum, then it is much easier for the experts to point out the stumbling blocks.     

Thanks.

December 24, 2014, 11:44:04 AM
Reply #5

JK

  • *
  • Information
  • Newbie
  • Posts: 3
Hi,

once I have something, I don't mind sharing it at all. Maybe someone may want to use it for another char device or similar. But due to work and other commitments, the whole project (or this part) is still on hold. I will give updates as soon as I actually have some ;)

Happy holidays!