• ModuleMania Animated

    SUF04/13/2016 at 16:32 0 comments

    My first attempt to create an animation in OpenSCAD: How the modules will fit into the enclosure:

  • ModuleMania

    SUF04/09/2016 at 07:09 0 comments

    As I'm thinking further, it become obvious that I want to create a modular system. Something like a backplane, with equaly sized modules, the sensors, the actuators, the MCU, and the power source also reside on separate modules.

    Even I went further. Designed a box, the backplane and the module form factor already. The modules will be implemented in 5x5cm form factor. Why? Because this can be cheaply ordered from the Chinese PCB factories - ~$10 for 10pcs.

    The planed module connector has 1 SPI, 1 I2C and 8 GPIO connections. This is 17 pins together with the two power rails (3.3V and 5V). A 17 pin 0.1" single row header fits onto the 5cm edge of the board.

    As I'm going further with it, I came up with quite a few modules, I want to implement. The list isn't complete, and the modules are subject to change:

    • Relay - Single channel relay module
    • RCR - Module for the rolling code receiver
    • Power sensor - Sensing if a mains voltage exists at a perticular point
    • Temp/humidity - AM2302 based module (the sensor can be fitted internally or connected externally)
    • Esp01 - ESP-01 based "brain" module switchable between two GPIOs and an I2C
    • Esp07/12 + pcf8574 - ESP-07 or ESP-12 based module with an I2C extender
    • Esp12e/f - Questionable. Can be created if the internal flash SPI ports are shareable with external SPI devices easily - testing needed
    • Arduino + nrl24l01+ - MySensors.org sensor node "brain"
    • PSU - 5V/3.3V capable PSU based on HLK-PM01 and 3.3V LDO or buck converter
    • Nrl24l01+ - Nordic communication module - used primary for the Beaglebone to create MySensors.org gateway
    • Barometric pressure sensor
    • Bus Extender
    • Power Meter, Current transformer type
    • Power Meter, Hall sensor type
    • Power Meter, Utility meter pulse counter
    • Gas Utility meter Hall sensor
    • SSR Module
    • GPIO Module - Isolated I/O Module, a DC/DC converter may added

    In addition I plan to design Backplane for 4, 6 and 8 modules. The backplane will have an additional connector, what is able to connect the whole thing to a BeagleBone CAPE. This means, I'll able to use this modular system for the BBG based OpenHAB central also.

    I also adding parametric 3D printable enclosure for it.

    Some of the modules already designed. Although it can be ordered from a fab, but all of the designs ready until today uses single sided board, what can be easily created at home with toner transfer. Most (not all) of the designs uses exclusively trough hole components, what make the life easier.

  • Mains Voltage Sensor

    SUF04/02/2016 at 21:19 0 comments

    No, I don't want to measure the mains voltage (yet) here.

    I want to build my garage lamp switch as minimally invasive to our current setup, as I can.

    What does that mean?

    The lamp today is switched by two wall switches (one inside the garage, one in the house at the garage door) in alternating configuration. I want to keep the possibility to operate the lamp with this switches. As I'm not an electrician, I not really want to touch the wires, switches inside the wall (it would be a dirty job anyways). Fortunately I've continuous mains source also at the lamp itself.

    So the plan is to connect the remote switching unit to the uninterrupted source and sense if the switches are on or off. This signal will be used to alternate the lamp and not to determine the status. Every time it change (from on to off or off to on), will change the light state.

    For the sensing I need some electronics. The mains is not a child play so the proper isolation is crucial.

    I want to stick to the simplest circuit possible:

    A capacitive non-isolated power supply (two caps, two resistors, a diode and a zener) plus an optoisolator. The whole thing cost around $1.

    Here is the design:

  • Connecting the Heating

    SUF03/26/2016 at 04:33 1 comment

    As I mentioned earlier I've several Conrad (ELV) FHT80B thermostats, with radio controlled valves, and I've a CUL v3.2 device. Now I'm try to connect these devices to my OpenHAB.

    Before I started to work on this project I updated the firmware in the CUL to the one suggested for OpenHAB from here:

    http://culfw.de/culfw.html

    The references for the connection can be find here:

    https://github.com/openhab/openhab/wiki/FS20-Binding
    https://github.com/openhab/openhab/wiki/CUL-Binding

    Setting up the binding:

    1. Copy the required addons into the /opt/openhab/addons folder:

    org.openhab.io.transport.cul-1.8.1.jar
    org.openhab.binding.fht-1.8.1.jar

    If you have other devices than the heating from the FS20 family you may need the

    org.openhab.binding.fs20-1.8.1.jar

    also.

    2. Edit the configuration file /opt/openhab/configurations/openhab.cfg. Add the following to the end:

    fht:device=serial:/dev/ttyACM0
    fht:baudrate=38400
    fht:parity=0
    fht:husecode=XXXX

    The housecode is your choice. It is a four digit hexadecimal code. And it is absolutely necessary. If you don't provide it here, your system will not start without even a sign of the problem. You can just see the error message when you switch on the debug logging.

    This code will be the code of your CUL device and has no connection with the codes of the FHT80b devices. In addition if you want to get readings from your devices, you have to be sure, that the "CEnt" setting in each of FHT80B devices is set to "nA".

    3. You have to create some items in your items file for your FHT80B device. Something like this:

    Number fhtRoom1Desired "Desired-Temp. [%.1f °C]" { fht="housecode=552D;datapoint=DESIRED_TEMP" }
    Number fhtRoom1Measured "Measured Temp. [%.1f °C]" { fht="housecode=552D;datapoint=MEASURED_TEMP" }
    Number fhtRoom1Valve "Valve [%.1f %%]" { fht="housecode=552D;address=00;datapoint=VALVE" }
    Switch fhtRoom1Battery "Battery [%s]" { fht="housecode=552D;datapoint=BATTERY" }
    Contact fhtRoom1Window "Window [MAP(en.map):%s]" { fht="housecode=52FB;address=7B;datapoint=WINDOW" }
    The housecode in the example is the code of the FHT80B device itself. You can read it from the device, the code1 is the first part, the code2 is the second part, and you must convert your readings to hexadecimal.

    4. Now you have to insert the read values into your sitemap:

    Frame label="Heating"
    {
    	Setpoint item=fhtRoom1Desired minValue=6 maxValue=30 step=0.5 
    	Text item=fhtRoom1Measured
    	Text item=fhtRoom1Valve 
    	Text item=fhtRoom1Battery
    	Text item=fhtRoom1Window
    }
    The result is something like this:


    Sorry for the Hungarian text, as this is a real data from my house, I'll translate the whole frontend to Hungarian to my family.

    One thing to add: Be patient. Getting the data is a time consuming task. Some of the data will just arrive when changed. So it can take several minutes, or even hours, to get your data.


  • Switching the Lamp (a LED)

    SUF03/22/2016 at 21:36 0 comments

    Going further. This is just a copy-paste programming.

    I grabbed the Arduino code from here:

    http://iot-playground.com/blog/2-uncategorised/40-esp8266-wifi-relay-switch-arduino-ide

    Changed the SSID and the password, connected a 150ohm resistor and the first LED I found in my junk box to the corresponding pins of the ESP8266. Downloaded the code, and fired the serial monitor in the Visual Studio:

    When I connect to the web server from a browser, I can switch the LED on and off.

    Now integrate it to the OpenHAB.

    We don't need anything else just modify the previously created rules. First I just added the http calls into the previously created rule, but the result wasn't satisfactory. I was able to control the LED from the remote, but not from the web browser. So I modified it a bit more.

    Here is the result:

    import org.openhab.core.library.types.*
    import org.openhab.core.persistence.*
    import org.openhab.model.script.actions.*
    
    rule "GarageLightRemote"
    when
        Item KeeLoq_Remote_B changed from CLOSED to OPEN
    then
        if(Garage_Light.state == ON)
        {
            sendCommand(Garage_Light, OFF)
        }
        else
        {
            sendCommand(Garage_Light, ON)
        }
    end
    
    rule "GarageLightOffAction"
    when
        Item Garage_Light changed from ON to OFF
    then
            sendHttpGetRequest("http://10.1.2.129/gpio/0")
    end
    
    rule "GarageLightOffAction"
    when
        Item Garage_Light changed from OFF to ON
    then
            sendHttpGetRequest("http://10.1.2.129/gpio/1") 
    end

    Here is the circuit:

  • ESP8266, Arduino, Visual Studio

    SUF03/22/2016 at 12:53 0 comments

    I'm not a big fan of the whole Arduino ecosystem. The hateful IDE, and the lack of the debug-ability kept far from it.

    On the other side I must admit that it is evolved since my first encounter, and it looks like something unavoidable.

    I need some remote sensors, actuators, for my OpenHAB system. I want to build most of them. As I looked around, I seen two easily usable solution:

    ESP8266 based WiFi modules

    MySensors.org NRF24L01+ and Arduino based mesh network

    I want to try both of them. As I not really have Arduinos on hand yet (actually I've few but different manufacturers, different hassles, and not really fits into this project), so I want to start to play with the ESP8266.

    As I heard the LUA interpreter of it not really fits into bigger project, so I chosen the Arduino framework for it. Actually I'm just learning it, so I don't know where this lead to.

    My first goal to be able to switch a GPIO of the ESP8266 via a HTTP REST API interface.

    As I mentioned above I really hate the Arduino IDE. I run into various problems with it when I tried to configure and compile the Marlin firmware for my 3D printer. Then I found that you can use the trusted Microsoft Visual Studio (I'm using it for my daily work and a few contract projects) with this addon:

    http://www.visualmicro.com/

    for the task.

    Putting together the environment:

    1. Install an Arduino IDE. Can be downloaded from here: https://www.arduino.cc/download_handler.php?f=/arduino-1.6.8-windows.exe

    2. Install the Microsoft Visual Studio 2015. I'm using the Professional version, but there is a free version, can be downloaded from here: https://go.microsoft.com/fwlink/?LinkId=615448&clcid=0x409

    Make sure that you enable the C++ component

    3. Start the Visual Studio. Go into the Tools/Extensions and Updates menu. Select the Online in the left pane. Search for Arduino

    Download the Arduino IDE for Visual Studio

    Install it, and restart Visual Studio as instructed.

    4. After restart the Arduino configuration will appear. You should set the Arduino IDE location and add the ESP8266 Board Manager URL: http://arduino.esp8266.com/stable/package_esp8266com_index.json

    Press OK

    5. On the menu bar next to the Arduino board selector click on the magnifying glass icon

    select the Manage Boards tab

    Expand the esp8266 and click on the Version 2.1.0

    On the popup dialog Click OK for the installation

    And this is the point where I run into a great trouble. My machine is part of a domain, I'm running things as a regular user, means I've limited permissions (of course I'm admin on the other side, but I should specify it when I need it). It looks like the installer have a bug. Because I'm domain member and when I installed the machine at the beginning the user name I gave is the same I use in the domain. The result of this, that my profile name in the c:\Users folder is looks like this: <username>.<domainname>. This caused no problems in the past, but not here. The installer converted the dot between the name and the domain to underscore in some places and gave me an access denied error - yes because the folder in question didn't exists and I've no right to create it.

    So I created the folder as admin and granted permission for me. After this the install run smoothly, but when I wanted to compile my first code, it failed. The error message wasn't too informative. After several trials, even using Process Monitor (Microsoft, formally Sysinternals tool), I was able to copy the files left in the temp folder under the underscore user folder I created, back into its place. Now it works, several hours wasted.

    6. Try this out

    I wanted to have a fast test, so I just created a demo project. The blink from the Visual Studio project list.

    After selecting the correct board (NodeMCU v0.9 in my case) and the serial port, just uploaded the code and it started to work.

    It looks like the ESP8266 environment is ready for more complicated tasks.

  • Rolling code receiver - Integration

    SUF03/19/2016 at 06:17 0 comments

    To be able to use the rolling code receiver in my OpenHAB, the first thing we need to enable the GPIO binding in the OpenHAB. There is a fairly good documentation of it in the OpenHAB wiki:

    https://github.com/openhab/openhab/wiki/GPIO-Binding

    I mostly done, what is in it, but some modifications were needed.

    1. Install the native JNA library:

    apt-get install libjna-java

    2. Modify /opt/openhab/start.sh
    Add -Djna.boot.library.path=/usr/lib/jni into the list of java command line parameters

    3. Modifiy the /etc/init.d/openhab

    Add -Djna.boot.library.path=/usr/lib/jni into the DAEMON_ARGS parameters

    and add the commands to unexport the gpio pins on stopping the daemon

    4. From the previously downloaded distribution-1.8.1-addons.zip (part of the OpenHAB downloads) expand the following files:

    org.openhab.io.gpio
    org.openhab.binding.gpio
    into the /opt/openhab/addons directory

    5. Restart openhab:

    /etc/init.d/openhab restart

    Now the OpenHAB is ready to handle the GPIO. We need to make the configuration changes, to be able to use it.

    6. Add the required items

    The GPIO inputs can be represented by Contacts in the OpenHAB, so edit one of the files in the /opt/openhab/configurations/items directory (I already dropped the demo config from here, so I've the config of my house) and add the following:

    Contact KeeLoq_Remote_A "Remote A [MAP(en.map:%s]" (<ID of your Group>, Windows) { gpio="pin:66"}
    Contact KeeLoq_Remote_B "Remote B [MAP(en.map:%s]" (<ID of your Group>, Windows) { gpio="pin:67"}
    Contact KeeLoq_Remote_C "Remote C [MAP(en.map:%s]" (<ID of your Group>, Windows) { gpio="pin:69"}
    Contact KeeLoq_Remote_D "Remote D [MAP(en.map:%s]" (<ID of your Group>, Windows) { gpio="pin:68"}

    When everything is fine you should see the following after the OpenHAB reload the configuration:

    And when you push a button on the remote, the closed text change to open, and back when you release.

    7. For the lighting it will not be enough

    We need to keep the status of the light, as it switched on or off. So I added a Switch into the items config:

    Switch Garage_Light "Garage Light" (<ID of your Group>, Lights)

    This is only a regular switch, so if you want to control it from the remote you need some rules. You can add it to a rules file in the /opt/openhab/configurations/rules folder:

    rule "GarageLightToggle"
    when
        Item KeeLoq_Remote_B changed from CLOSED to OPEN
    then
        if(Garage_Light.state == ON)
        {
            sendCommand(Garage_Light, OFF)
        }
        else
        {
            sendCommand(Garage_Light, ON)
        }
    end
    After this, when you push the B button on the remote, it will switch the web control, on and off

    This still not change the physical light. I have to create/buy some actor for this.

  • Rolling code receiver

    SUF03/19/2016 at 04:25 0 comments

    [2016.04.16]: When I wrote this article didn't realized, that I used the old location of the cape manager slots file. Corrected.

    When you sit in your car and try to enter to your garage, I know it is not fancy, but the most convenient device is the tiny remote you can hang on your keyring (something integrated into your car would be better and fancier, I may add something like this later on).

    To be able to remote control the OpenHAB and the garage door/lights through it, I bought this rolling code receiver on the aliexpress:

    http://www.aliexpress.com/item/RF-Rolling-Code-Decoding-Receiver-Module-2-Transmitters-DC-5V-4CH-TTL-Output-Learning-Momentary-Toggle/32295201884.html

    My plan is to use it for switching the lights in the garage, control the garage doors and a few more (as it has two more buttons - exactly two) tasks.

    First I put this onto a breadboard, powered up, and tried out if it works.

    It was working for the first try, finding out the different channels for the buttons was easy like a child's play.

    The only problem with the device, that it has 5V logic outputs and I want to connect to my BeagleBone Greens GPIO what isn't 5V safe.

    I decided to use the simplest level shifter on earth possible. A resistor divider. A 39K and a 68K resistor does its job like champ, if you measure it with a multimeter.

    The next part is to setup the GPIO on the BeagleBone. The OpenHAB uses the Linux GPIO Sysfs interface, what is supereasy to use (https://www.kernel.org/doc/Documentation/gpio/sysfs.txt).

    First I tried to read the data from the command line. Connected one channel to the GPIO_60 (P9 pin 12) of the BBG.

    On the console the following commands are needed:

    echo '60' > /sys/class/gpio/export
    echo 'in' > /sys/class/gpio/gpio60/direction

    After this you can read the pin value by the following command:

    cat /sys/class/gpio/gpio60/value

    The commands went well, but doesn't matter if I push the button on the remote or not, always get back a 1.

    Measured the input with a multimeter. It gives 1.6V even the pin of the receiver is on 0V. This means, that the BBG input pin is pulled up.

    From this point I've two choice:

    1. Switch of the pull up somehow

    2. Use some active circuit as level shifter instead of the resistors.

    I went for the first one.

    Looked around and it clearly turned out, that changing the pull-up is not part of the linux GPIO framework. Read many things and found that BBG uses Cape Manager Overlays for this task. It was sometimes there, sometimes not, but on the 4.1.x kernel what I'm using is already part of the mainline kernel.

    Here are some articles about it:

    https://github.com/jadonk/validation-scripts/blob/master/test-capemgr/README.md
    http://www.thing-printer.com/cape-manager-is-back-baby/
    http://www.valvers.com/embedded-linux/beaglebone-black/step04-gpio/

    The overlay repository (you can learn from it, but not necessary for the task here):
    https://github.com/RobertCNelson/bb.org-overlays

    The most useful of my findings was this online tool:

    http://kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator

    It is able to create the overlay you need.

    So for switching off the pull-up on Gpio 60 above you have to do the following things:

    1. Save this file into the /lib/firmware under the name bspm_p9_12_2f-00A0.dts

    /*
     * This is a template-generated file from BoneScript
     */
    
    /dts-v1/;
    /plugin/;
    
    /{
        compatible = "ti,beaglebone", "ti,beaglebone-black";
        part_number = "BS_PINMODE_P9_12_0x2f";
    
        exclusive-use =
            "P9.12",
            "gpio1_28";
    
        fragment@0 {
            target = <&am33xx_pinmux>;
            __overlay__ {
                bs_pinmode_P9_12_0x2f: pinmux_bs_pinmode_P9_12_0x2f {
                    pinctrl-single,pins = <0x078 0x2f>;
                };
            };
        };
    
        fragment@1 {
            target = <&ocp>;
            __overlay__ {
                bs_pinmode_P9_12_0x2f_pinmux {
                    compatible = "bone-pinmux-helper";
                    status = "okay";
                    pinctrl-names = "default";
                    pinctrl-0 = <&bs_pinmode_P9_12_0x2f>;
                };
            };
        };
    };
    2. Compile it:
    dtc -O dtb -o /lib/firmware/bspm_P9_12_2f-00A0.dtbo -b 0 -@ /lib/firmware/bspm_P9_12_2f-00A0.dts
    3. Load it:
    echo bspm_P9_12_2f > /sys/devices/platform/bone_capemgr/slots...
    Read more »

  • Install OpenHAB

    SUF03/16/2016 at 10:57 0 comments

    Now here I install OpenHAB as the home automation controller, the brain of the whole system.

    The OpenHAB is a java based system, so first we need an Oracle Java. To achieve this you have to add a PPA repository to the system:

    BTW. I know that the sudo voodoo is absolutely necessary to keep the security. Even I'm working on my windows machine as a standard user and not admin since XP when the UAC wasn't even planed. But when I put together something on linux or windows and what I'm doing is clearly administrative task, I'm doing it as admin. So the first thing when I install several things, packages, etc. on linux I start with

    sudo su

    And don't bother to write sudo at beginning of every single line.

    1. Add PPA repository of the Oracle Java and install it.

    apt-get install software-properties-common
    add-apt-repository ppa:webupd8team/java
    apt-get update
    apt-get install oracle-java8-installe
    

    2. Download OpenHAB files. You will need this ones:
    https://bintray.com/artifact/download/openhab/bin/distribution-1.8.1-runtime.zip
    https://bintray.com/artifact/download/openhab/bin/distribution-1.8.1-addons.zip
    https://bintray.com/artifact/download/openhab/bin/distribution-1.8.1-demo.zip

    Actually I usually download the files on my Windows machine and transfer them to the linux via WinSCP

    3. Extract the files, create configuration

    mkdir /opt/openhab
    unzip distribution-1.8.1-runtime.zip -d /opt/openhab/
    unzip distribution-1.8.1-demo.zip -d /opt/openhab/
    cp /opt/openhab/openhab_default.cfg /opt/openhab/openhab.cfg

    4. As we still in sudo mode we can start the OpenHAB server to test the functionality of our system:

    /opt/openhab/start.sh

    After waiting for a while, we can test in a browser if it works:

    http://<ip address>:8080/openhab.app?sitemap=demo

    OK. Our server works, but we not yet finished. Just stop it now.

    First: you may realized that I didn't created any specific user for the openhab. There is a reason why.

    The Ubuntu not really designed for embedded systems. Therefore no mechanism (what I'm aware of) for regular user to access GPIO (if you know a simple method for it please don't keep inside). On the next part I want to use GPIO. Based on this I plan to run OpenHAB as root.

    Second: I need a method to run OpenHAB as daemon So..

    5. Download the daemon script from here:

    https://github.com/openhab/openhab/wiki/Samples-Tricks#how-to-configure-openhab-to-start-automatically-on-linux

    Save as openhab into the /etc/init.d folder

    Configure it:

    chmod a+x /etc/init.d/openhab
    update-rc.d openhab defaults

    Edit the file with your favorite editor. Most probably you only need to change the RUN_AS from openhab to root

    Start it:

    /etc/init.d/openhab start
    Now you can check it again if it still works via a web browser, and you can check the /var/log/openhab.log for errors.

  • Into my safety zone

    SUF03/15/2016 at 08:41 0 comments

    Ok. So let start:

    I'm not a linux guru. There are many favors of linux distribution, but I've just some experience with Ubuntu and Debian. In addition I usually not using any linux GUI.

    So when I start a linux based project, it means to install an Ubuntu.

    As I decided, this project will be based on a Beaglebone Green. Let start to install a 14.04 LTS to it.

    The basic information reside here: http://elinux.org/BeagleBoardUbuntu

    1. You need to download the image from here: https://rcn-ee.com/rootfs/2016-02-11/flasher/BBB-eMMC-flasher-ubuntu-14.04.3-console-armhf-2016-02-11-2gb.img.xz

    (today the 16.04 image already exists, but I stick to the older as it seems more stable), download the image writing tool (Win32DiskImager): https://sourceforge.net/projects/win32diskimager/files/latest/download

    And you need an empty minimum 2GB uSD card.

    2. Expand the image to a folder in you machine. For example the 7-Zip will do it. Install the Win32DiskImager.

    3. Write the image to a uSD card with the Win32DiskImager


    4. When the writing is finished, insert the uSD card into the Beaglebone. Press and hold the boot select button (the one close to the uSD slot) while powering up the board. After short booting sequence you will see the "knight rider pattern" on the LEDs. Wait until it finish and the leds turn on.

    5. Connect the board to the ethernet network. If you can figure out the address get by DHCP the steps from 6-8 are optional. Just reboot the board by power cycling it.

    6. Install the PC driver for the board (if you have a BeagleBone Green, this is absolutelly necessary as you don't have HDMI connector to connect monitor). The windows driver can be downloaded from here:
    64 bit: http://beagleboard.org/static/beaglebone/latest/Drivers/Windows/BONE_D64.exe
    32 bit: http://beagleboard.org/static/beaglebone/latest/Drivers/Windows/BONE_DRV.exe
    This is NOT a serial driver as you expect, but a virtual ethernet driver. You will need an SSH terminal to connect to Beaglebone.

    7. Connect the Beaglebone to your PC. If it is was connected already, just cycle the power on it with removing and reconnecting the USB cable, when you disconnect the cable you can remove the uSD card, as you don't need it anymore.

    8. If you run ipconfig on your machine a new ethernet interface will appear:

    You'll get 192.168.7.1 as a new interface on your machine, the Beaglebone will appear on the 192.168.7.2. You can connect to it with an SSH terminal like PuTTY

    9. If you didn't used the USB/Ethernet to log in, just login via the DHCP provided IP address. If you need static IP address edit the /etc/network/interfaces file and setup the address.

    10. If you check the DNS settings of the system it is probably not working. Just by editing the /etc/resolv.conf will not resolve the problem, as it gets overwriten on the next reboot.

    Edit the /etc/resolvconf/interface-order file and put eth* to the first on the list. This will give you the correct DNS settings.

    11. Reboot the board.

    12. Install the updates with:

    apt-get update

    apt-get upgrade