Welcome to BigJungle Ltd

Exploring technology, IoT innovations, and open-source projects. From smart home automation to industrial IoT solutions.

Latest Posts

  • Jun 7, 2016

    FarmBot is an open-source CNC farming machine

    “With hopes of reinventing the way food is grown, Rory Aronson has developed humanity’s first open-source CNC farming machine. The FarmBot Genesis — which will begin taking pre-orders in July — is capable of planting seeds and then watering them precisely.”

    — https://blog.arduino.cc/2016/06/07/farmbot-is-an-open-source-cnc-farming-machine/

    Arduino.cc have a nice write up of what looks to be a nice open source project; FarmBot Genesis

    The FarmBot Genesis represents an exciting development in agricultural automation, combining open-source hardware with precision farming techniques. This CNC-style farming machine can autonomously plant seeds, water crops, and tend to gardens with minimal human intervention.

    Key features of the FarmBot Genesis include:

    • Open Source Design: Complete hardware and software designs are freely available
    • Precision Agriculture: Computer-controlled planting and watering systems
    • Modular Construction: Expandable and customizable for different garden sizes
    • Web Interface: Monitor and control your FarmBot remotely
    • Arduino-based: Built on familiar open-source hardware platforms

    This project exemplifies the potential of combining traditional agriculture with modern IoT and automation technologies.

    Smart Garden Arduino
  • Apr 13, 2016

    EmonCMS and multiple OpenTRV nodes

    As a follow up on my initial experiments with getting data from OpenTRV to Open Energy Monitor, this post is going to build on that and add support for parsing data received from the other OpenTRV nodes other than the one directly connected via the USB serial.

    The Hardware

    The hardware I am using is a Rev 2 board as the receiver as described previously and the transmitters are two Rev 11 boards. Due to the design of the firmware however this should work the same on any of the devices.

    Firmware

    To get these to talk to each other we need to ensure the firmware for on the receiver device has the ENABLE_STATS_RX build option defined and on the transmitting end ENABLE_STATS_TX needs to be defined.

    Testing

    With the new firmware built and flashed it is time to power up and see what we get. Load up the Node-RED UI with the work sheet we created last time. Turn off all the debug nodes apart from the last one of the switch node. This will now only show the console output we are not parsing, (you may need to wait about 10 mins to see anything).

    You should see some JSON output that looks suspiciously like the end of the status lines from last time. It is probably of no surprise that in fact in is the same format as the JSON part of the status text. So we already have the code to parse this text.

    Parsing The Output

    First things first though, we need to separate out the JSON lines from the rest of the unhandled Lines. Double click on the switch node and add a new entry above the otherwise entry. Set this to look for a regex and enter the following:

    ^{

    This will now pull out the JSON by detecting the opening {.

    Now connect a new function node to a new switch output and grab the JSON code we wrote before:

    var obj = JSON.parse('{'+parts[16]+'}');
for(var i in obj) 
{
    switch(i)
    {
        case '@':
            break;
        case 'T|C16':
            break;
        default:
    }
}

    We have to make a few changes to make this stand alone. First the JSON is coming from msg.payload rather than parts[16] and we are going to write the parsed output back directly to msg.payload. The reason for this will become clear soon.

    var json = msg.payload;
msg.payload = {};

var obj = JSON.parse(json);
for(var i in obj) 
{
    switch(i)
    {
        case '@':
            break;
        case 'T|C16':
            break;
        default:
    }
}

return msg;

    Sending to EmonCMS

    Now all that is left to do disconnect the function output to the EmonCMS node, or is it? You may have noticed I the previous example that we entered the EmonCMS node ID in the settings of the EmonCMS node in Node-RED. Now we are receiving from more than one OpenTRV device we need to translate the OpenTRV ID to an EmonCMS node ID. So we need to write a function to map the IDs from one system to another.

    Place a function node after the two parsing nodes and before the EmonCMS node:

    Our parsing code is writing the OpenTRV ID in to msg.nodeid and if the Node setting is left blank the EmonCMS node will use msg.nodegroup for the Node. This can be done with the following:

    var nodeMapping = {
    'f9ea': 26,
    'a7de': 27
};

if(msg.nodeid && nodeMapping[msg.nodeid]) {
    msg.nodegroup = nodeMapping[msg.nodeid];
}

return msg;

    You will need to alter the content of nodeMapping for your environment.

    As we are dealing with more than just msg.payload it is handy to debug the whole msg object. To do this you can open a debug node’s settings (double click it) and change the Output to complete msg object.

    The other change we need to make is to clear the fixed Node setting in the EmonCMS node. Open the EmonCMS node settings and delete anything in the Node setting. Don’t worry if the setting highlights red, this can be ignored as we are passing in the setting for this value. A warning may also be given when deploying, this too can be ignored.

    We can now deploy the sheet and it should look something like this.

    If all is working you should now see all the OpenTRV nodes showing data in your EmonCMS.

    Making Improvements

    We could leave it there, but there is a bit of tidy up we can do to help reduce the maintenance. For example the newer versions of the firmware send the battery level using B|cV. To add support for this we would have to edit two similar pieces of code. We can easily update the code to put all the JSON parsing in a single node.

    Instead of parsing the JSON in the OpenTRV Parse Status we can pass the JSON along to the OpenTRV Parse JSON node so it can be parse there. Let’s disconnect the output of the OpenTRV Parse Status from the EmonCMS node and to the input of the OpenTRV Parse JSON so we have a unified parsing approach.

    This approach provides a more maintainable solution for handling multiple OpenTRV nodes and ensures consistent data processing across all connected devices.

    Smart Home Energy Monitoring
  • Mar 9, 2016

    Experiments with Node-RED

    After getting my heating and power usage/generation into EmonCMS I wanted to start pulling other sources of data into EmonCMS, so I started looking for a more expandable method to bring multiple sources of data into EmonCMS.

    Open Energy Monitor, the folks behind EmonCMS, have recently started looking at Node-RED so I decided to also have a look at this.

    It is also getting colder and I wanted to get a bit more information on the operation of my OpenTRV board that has been sitting underused since the spring when I installed it on the radiator in the office.

    Getting Started

    I won’t go into detail about downloading/installing Node-RED as there are good instructions in the Node-RED documentation and the Node-RED EmonCMS Node blog post includes instructions on installing the EmonCMS specific components.

    First of all we need to get the data from the OpenTRV devices. In my setup this is via a USB to TTL adapter connected to the serial data port on the OpenTRV.

    That is it for the hardware, but how do we get the data into Node-RED? For this we need the Serial node.

    Setting Up the Serial Connection

    Drag one of these nodes to the workspace and double click to open the settings. You’ll need to configure:

    • Serial Port: The COM port your USB-TTL adapter is connected to
    • Baud Rate: Typically 4800 for OpenTRV devices
    • Data Bits: 8
    • Parity: None
    • Stop Bits: 1

    Data Processing

    The OpenTRV devices output status information in a structured format that includes temperature readings, valve positions, and other sensor data. Node-RED provides excellent tools for parsing this data:

    Switch Node

    Use a switch node to route different types of messages based on content patterns.

    Function Nodes

    Create custom JavaScript functions to parse the OpenTRV status strings and extract meaningful data points.

    Debug Nodes

    Essential for monitoring data flow and troubleshooting your Node-RED flows.

    Integration with EmonCMS

    Once you have the data parsed and formatted, the EmonCMS node makes it simple to send the data to your EmonCMS instance:

    1. Install the EmonCMS Node: Use the Node-RED palette manager
    2. Configure Connection: Set your EmonCMS server URL and API key
    3. Map Data: Ensure your parsed data matches the expected EmonCMS format

    Benefits of Node-RED

    Using Node-RED for IoT data integration provides several advantages:

    • Visual Programming: Flow-based programming makes complex data processing easier to understand
    • Extensive Library: Thousands of contributed nodes for different protocols and services
    • Real-time Processing: Live data transformation and routing
    • Easy Debugging: Built-in debugging tools and message inspection
    • Flexible Deployment: Can run on Raspberry Pi, local servers, or cloud platforms

    Next Steps

    This initial experiment with Node-RED has opened up many possibilities for expanding my home automation and monitoring system. Future posts will explore:

    • Handling multiple OpenTRV nodes
    • Adding other sensor data sources
    • Creating custom dashboard interfaces
    • Advanced data processing and alerting

    Node-RED proves to be an excellent tool for bridging different IoT protocols and services, making it much easier to create comprehensive monitoring and automation systems.

    Smart Home Node-RED
  • Aug 20, 2015

    Raspberry Pi FTDI Shim

    When working with embedded systems and IoT projects, having reliable serial communication is essential. The Raspberry Pi’s GPIO header provides UART functionality, but sometimes you need the convenience and isolation of an FTDI USB-to-serial adapter.

    The Problem

    While the Raspberry Pi has built-in UART pins on the GPIO header, there are several scenarios where an external FTDI adapter is preferable:

    • Isolation: Protecting your Pi from potential voltage issues
    • Convenience: Easy plug-and-play serial access
    • Multiple Connections: Using the Pi’s UART for other purposes
    • Development: Easier debugging and logging during development

    The Solution: FTDI Shim

    An FTDI shim is a small adapter board that bridges the gap between standard FTDI breakout boards and the Raspberry Pi GPIO header. This simple but effective solution provides:

    Key Features

    • Direct GPIO Connection: Plugs directly into the Pi’s GPIO header
    • Standard FTDI Pinout: Compatible with common FTDI breakout boards
    • Power Options: Can provide 3.3V or 5V power to connected devices
    • Compact Design: Minimal footprint and low profile
    • Easy Access: Other GPIO pins remain accessible

    Pinout Mapping

    The shim typically maps the following connections:

    FTDI Pin Pi GPIO Pin Function
    GND GND Ground
    VCC 3.3V/5V Power
    RX GPIO 14 TX
    TX GPIO 15 RX
    DTR Not used -
    CTS/RTS Optional Flow Control

    Use Cases

    This setup is particularly useful for:

    OpenTRV Development

    When working with OpenTRV thermostatic radiator valves, the FTDI connection provides:

    • Easy firmware flashing
    • Real-time status monitoring
    • Debug output capture
    • Configuration updates

    Arduino Communication

    For projects involving Arduino boards:

    • Programming ATmega microcontrollers
    • Serial debugging and monitoring
    • Data logging from sensors
    • Bootloader installation

    General Serial Devices

    Any device requiring serial communication:

    • GPS modules
    • Sensor networks
    • Display modules
    • Custom embedded projects

    Assembly and Installation

    The FTDI shim is typically a simple PCB that requires minimal assembly:

    1. Solder Headers: Attach male pins for GPIO connection and female socket for FTDI board
    2. Check Connections: Verify pinout matches your specific FTDI breakout
    3. Power Selection: Ensure voltage levels match your target device
    4. Install: Plug into Pi GPIO header and connect FTDI board

    Software Configuration

    To use the FTDI connection with your Raspberry Pi:

    # Check for USB serial device
lsusb | grep FTDI

# List serial devices
ls /dev/ttyUSB*

# Connect using screen
screen /dev/ttyUSB0 9600

# Or use minicom
minicom -D /dev/ttyUSB0 -b 9600

    Benefits

    The FTDI shim approach offers several advantages:

    • Flexibility: Easy to connect/disconnect serial devices
    • Reliability: Proven FTDI chips provide stable communication
    • Debugging: Excellent for development and troubleshooting
    • Isolation: Protects Pi from electrical issues
    • Portability: FTDI connection works with any computer

    Conclusion

    The Raspberry Pi FTDI shim is a simple but valuable tool for anyone working with serial communication in IoT and embedded projects. Its ease of use and reliability make it an essential component in the embedded developer’s toolkit.

    Whether you’re flashing firmware, debugging sensor networks, or monitoring data streams, this small adapter can significantly improve your development workflow and system reliability.

    Hardware Raspberry Pi

View all posts | Subscribe via RSS