Navigation

    • Register
    • Login
    • Search
    • OpenHardware.io
    • Categories
    • Recent
    • Tags
    • Popular
    1. Home
    2. Carywin
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    Carywin

    @Carywin

    24
    Reputation
    52
    Posts
    616
    Profile views
    0
    Followers
    0
    Following
    Joined Last Online

    Carywin Follow

    Best posts made by Carywin

    • MQTT/Ethernet Gateway using Leonardo(32u4), W5100, RFM69H, Hard SPI

      Hi Folks,

      I'm brand new at this MySensors thing, and I have struggled a lot trying to get a gateway going. I think I have mostly succeeded now though, so I thought I'd share how I got here and hopefully save others some trouble.

      I'm using Arduino Leonardo which is the Uno-like board that has the ATMega32u4 processor. It has a couple of differences from the '328 varieties that will trip you up if you're not careful (at least, they certainly tripped me up). The hardware SPI pins are on the ICSP header, and the interrupt pin for the radio triggers a different INT vector, for example.

      It's also a 5V chip, so I had to use a level converter for the radio module. I was lucky that my choice of prototyping shield for the Uno had a spot for SOIC-14 and so I populated it with TXS0104E and connected the radio through that. I connected the interrupt output from the radio module (DIO0) directly to the Atmel though.

      I had to use some tinned wire to extend the pins on the ICSP header so they would connect through the W5100 shield and into the prototyping shield that I mounted the radio on. I connected the RFM69 chip-select to pin 6 of the Arduino, and used 3, 5, 7 for the LEDs.

      I fumbled around for a long time before I realised that MySensors doesn't support the RFM69 module using SoftSPI. I think this should be made more clear on the Ethernet Gateway page. I ended up learning a lot about SPI and the W5100 Ethernet Shield, and came to the conclusion that the recent work on making SPI transactions atomic seems to have made sharing the SPI port possible. So I swapped out the RFM69 driver in the MySensors library with this one which includes the new SPI transaction features.

      My sketch is posted below and it's mostly the stock MQTT client gateway with the config set appropriately. The only other change was the RFM driver swap I mentioned above.

      *******************************
       *
       * REVISION HISTORY
       * Version 1.0 - Henrik Ekblad
       *
       * DESCRIPTION
       * The W5100 MQTT gateway sends radio network (or locally attached sensors) data to your MQTT broker.
       * The node also listens to MY_MQTT_TOPIC_PREFIX and sends out those messages to the radio network
       *
       * LED purposes:
       * - To use the feature, uncomment WITH_LEDS_BLINKING in MyConfig.h
       * - RX (green) - blink fast on radio message recieved. In inclusion mode will blink fast only on presentation recieved
       * - TX (yellow) - blink fast on radio message transmitted. In inclusion mode will blink slowly
       * - ERR (red) - fast blink on error during transmission error or recieve crc error
       *
       *
       */
      
      
      // Enable debug prints to serial monitor
      #define MY_DEBUG
      
      // Enables and select radio type (if attached)
      #define MY_RADIO_RFM69
      #define MY_IS_RFM69HW
      #define MY_RFM69_FREQUENCY RF69_433MHZ
      #define MY_RF69_IRQ_PIN 2
      #define MY_RF69_IRQ_NUM  1
      #define MY_RF69_SPI_CS 6
      
      #define MY_GATEWAY_MQTT_CLIENT
      
      // Set this node's subscribe and publish topic prefix
      #define MY_MQTT_PUBLISH_TOPIC_PREFIX "sensors-out"
      #define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "sensors-in"
      
      // Set MQTT client id
      #define MY_MQTT_CLIENT_ID "sensors"
      
      // Enable these if your MQTT broker requires usenrame/password
      //#define MY_MQTT_USER "username"
      //#define MY_MQTT_PASSWORD "password"
      
      // Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP)
      #define MY_IP_ADDRESS 192,168,1,30
      
      // If using static ip you need to define Gateway and Subnet address as well
      #define MY_IP_GATEWAY_ADDRESS 192,168,1,254
      #define MY_IP_SUBNET_ADDRESS 255,255,255,0
      
      // MQTT broker ip address
      #define MY_CONTROLLER_IP_ADDRESS 192,168,1,10
      
      // The MQTT broker port to to open
      #define MY_PORT 1883
      
      /*
      // Enable inclusion mode
      #define MY_INCLUSION_MODE_FEATURE
      // Enable Inclusion mode button on gateway
      //#define MY_INCLUSION_BUTTON_FEATURE
      // Set inclusion mode duration (in seconds)
      #define MY_INCLUSION_MODE_DURATION 60
      // Digital pin used for inclusion mode button
      //#define MY_INCLUSION_MODE_BUTTON_PIN  3
      */
      
      // Set LED blinking period
      #define MY_DEFAULT_LED_BLINK_PERIOD 300
      
      // Flash leds on rx/tx/err
      #define MY_DEFAULT_ERR_LED_PIN 3 //3
      #define MY_DEFAULT_RX_LED_PIN  5 //5
      #define MY_DEFAULT_TX_LED_PIN  7 //7
      
      
      #include <Ethernet.h>
      #include <MySensors.h>
      
      void setup()
      {
      }
      
      void presentation()
      {
      	// Present locally attached sensors here
      }
      
      
      void loop()
      {
      	// Send locally attached sensors data here
      }
      
      posted in My Project
      Carywin
      Carywin
    • RS485 Baud Rate Errors - Mixing HWSerial Devices Can Cause Problems

      Hi Folks,
      This is more of a troubleshooting report than a request for help. I thought I'd report my findings here in hopes of saving someone else the headaches I've had recently.

      What it boils down to is: the default clocks used on the common 3V3 and 5V Arduino boards cause small errors in actual baud rate on the hardware USART serial ports, and at certain rates the error difference between the two variants is opposite and results in no communications being possible between them.

      Some background:
      I have a small but growing RS485 MySensors network incorporated into my OpenHAB-based home automation system. It started out with just a MQTT gateway and a single node, being a weather station mounted up on the roof about 5 metres away. RS485 was chosen because getting RF signals through the metal roof was problematic, and I was sick of climbing up there to change batteries. Both the gateway and the WXS were built with 3V3 8MHz 32u4 based Arduinos, because then I could use the hardware USART port for RS485 comms while still having the USB port for debugging. Cat-6 cable was used, with one pair for the RS485 comms and a pair each for +12V and GND. The baud rate was set at 115200 bps and this setup worked flawlessly for about a year.
      So pleased was I with the reliability, that I decided all sensor nodes on my upper storey that had easy access for a cable would be wired nodes on the RS485 network going forward.
      The second node to be deployed on the network was a light/heat/fan controller for the bathroom. This node used a 5V 16MHz 32u4 Arduino. When built and tested on the bench, this node worked perfectly; but when deployed into the roof space and connected to mains power it flatly refused to work, spitting FPAR:NOREPLY errors forever. I spent a lot of time trying to troubleshoot the comms issues by investigating ground loops or other noise, termination, or power supply issues. I pulled the AC/DC supply off it and used the central +12V one. I changed the baud rates around and got some intermittent success. At one point I even fried both the Arduino and my laptop when some stray high-power-switching surges tried to find their way to ground through the USB cable. Nothing seemed to work in the roof, everything worked fine on the bench.

      After much longer scratching my head than I feel comfortable admitting I examined the differences between the MQTT gateway and my test setup, investigated how the oscillator clock is divided down to determine the baud rate, and stumbled upon the answer:

      at fosc = 8 MHz (3V3 parts), 115.2kbps, Error = -3.5%
      at fosc = 16 MHz (5V parts), 115.2kbps, Error = 2.1%
      Total error: 5.6%, somewhat outside the tolerable window of ~5% for baud rate error.

      In the end the solution was as simple as lowering the baud rate on the 5V 16MHz part by ~4% to 110600 bps. The new node then instantly connected and has been reliable ever since.

      posted in Troubleshooting
      Carywin
      Carywin
    • RE: 💬 MyMultisensors

      I've been slowly poking at these boards and I'm getting somewhere with the firmware, I should have something ready to put out there soon.

      In the meantime though I designed a quick snap-together enclosure that I'm sending off for "Dirty" 3D printing:
      0_1501094332438_render.png

      This is my first time using Fusion 360 and designing something for 3D printing, hopefully it goes okay.

      I wanted it to snap together in two halves around the board and be as low-profile as possible, hence why the base plate only covers half of the PCB and is mounted by one screw only. I designed it around using a CR2450 battery. I might also see if I can find a small lens or light pipe to put over the lux sensor so it gets a better read on the light level in the room.

      posted in OpenHardware.io
      Carywin
      Carywin
    • RE: 💬 MyMultisensors

      Okay, so here's some firmware I wrote for these multi-sensors: https://github.com/carywin/MySensors/tree/master/MyS_MultiSensor_revB

      Note that I'm currently using MySensors 2.2-beta from the development branch, to solve the some other problems I was having in my RFM69-based gateway. This sketch should still work fine with the released version of MySensors but I haven't tested it.I'm still testing and refining things here and there, but it should be a working base for people to build from. Of course you will need to change the MySensors #defines to match your network and radio settings.

      You'll probably notice that all of the sensors report under the same Child ID as a "Custom Sensor". This is because I'm using OpenHAB via an MQTT broker, so I don't really care if a certain sensor type matches with its provided variable types. If you're using a different controller, you may have to re-jig the Child ID/Variable types to match the known-working sensors on your controller.

      PIR Sensor:
      The PIR sensor is interrupt driven and will send a message when it receives more than 5 pulses in less than 5 seconds. After triggering, the interrupt is disabled for 60 seconds. If it receives fewer than 5 pulses then approx. 5 seconds after the last pulse it will reset the pulse counter. For the first 30 seconds after power-on, the PIR interrupts are disabled to allow the signal conditioning circuit time to settle. All of these values are configurable in the sketch. Note that I'm using GreyGnome's EnableInterrupt library, which you'll need to get from their Github.

      Lux Sensor:
      The lux level sensor will send a new reading to the controller when the lux reading moves outside a window threshold from the current reading, which is configurable in the sketch. It also takes a new reading after a certain period with no changes in lux, which is also configurable in the sketch.
      Note that you'll need the specific version of the OPT3001 library from the above link copied into your libraries folder. I modified the library to spit out raw values and allow the setting of thresholds, so the lux sensor can do most of the heavy lifting with regards to monitoring light levels and flagging an interrupt when it changes. Note that when the lux readings are very low, such as around sunrise and sunset, the threshold values are fixed to prevent excessive lux sensor messages.

      Door Sensor:
      The D3 pin input is set to trigger an interrupt on state change, which will send its new state to the controller on each change. It's pulled high by an on-board resistor so the input pullup is disabled to save energy.

      Temp & Humidity Sensor:
      Temperature and humidity are read at regular intervals (default 10 min), and new values only sent if the they have changed by 0.1 degC or 1% RH. If a certain number of intervals pass with no change (default 3 hours) they will send new values anyway. This way the controller can expire their readings after 3 hours and ignore stale values, and you can get an indication that maybe your sensor has failed. The interval times are configurable in the sketch. I'm using the Adafruit SI7021 library which you can get from their Github.

      Battery:
      Once a day by default the sensor will report battery voltage as a sensor, and remaining capacity as a percentage using the in-built reporting function. The full and empty thresholds as well as reporting interval are configurable in the sketch. Note that the method used to measure battery voltage has a large margin for error, but that this can mostly be calibrated out. For this reason you'll see a VCC calibration value that you should set by measuring each sensor's battery voltage with a multimeter, and comparing with its reported battery volts.

      WDT:
      I'm using the WDT during the time when the code isn't asleep, with a timeout of 2 seconds. This should be more than enough to send all of the sensor messages needed each cycle, but I haven't extensively tested that. I included it because in revision A I was suffering some kind of unknown lock up that would keep the MC awake and drain the coin cell battery in just a few hours. Of course the WDT is used by the library for timing the sleep intervals, so it gets re-enabled each wake up.

      Because timing how long an Arduino has been asleep is difficult without a RTC, the sleep time may vary somewhat depending on how many interrupts the sensor receives. Each time the MC is woken from sleep by an interrupt, it reduces the amount of time it will sleep next time by 25%. In addition to this, if more than 25 interrupts occur before a new round of sensor readings are taken, then the interval will be declared over and the sensors read again. These are crude methods for timing but so far it seem to be reliable in that the sensor neither sleeps forever nor spams excessively when receiving realistic rates of interrupt.

      I welcome any input people have on this project and ways that this might be improved.

      posted in OpenHardware.io
      Carywin
      Carywin
    • RE: 💬 MyMultisensors

      Thanks!
      I should have mentioned that I already set the BOD to 1.8V, but that doesn't help when the XTAL oscillator stops working at 2.6.
      I'll try one of those other bootloaders and see what flies.

      posted in OpenHardware.io
      Carywin
      Carywin
    • MQTT - RFM69 Gateway stops communicating randomly and doesn't recover

      Hi People,

      I have built a MySensors network based on RFM69H modules, with an Ethernet MQTT Gateway built on Leonardo which I detailed here: https://forum.mysensors.org/topic/6249/mqtt-ethernet-gateway-using-leonardo-32u4-w5100-rfm69h-hard-spi
      My three sensor nodes are mains-powered, a mix of Atmega328 and 32u4 doing temperature, environment, energy and HVAC control.
      I'm building on Windows 7, Arduino 1.8.1, MySensors 2.1.1

      It works really great most of the time, but I have an issue which has cropped up randomly and is starting to bug me a lot. Occasionally it seems like the gateway will just stop sending or receiving radio messages. None of the sensor reports get in nor do control signals get out. To resolve this I have to power cycle the gateway, and since I'm often away for long periods my system is completely paralysed until then. Sometimes it will work for a week or more without issue, and sometimes it will occur several times a day. I haven't been able to correlate the occurrences with anything that happens on the sensor network or the OpenHAB bus. Once I reset the gateway all of my other nodes re-join the network and start working again, so for now I have assumed they're all working properly and the fault lies within the gateway.

      I started logging the debug output from the gateway, and the issue has occurred twice since then. Both times it seems to be related to the radio receiving a garbage packet of some kind. After then it seems like the gateway code cannot talk to the radio module correctly, but doesn't seem to do anything about that eg. reset the radio. It seems to pass sanity checks okay and assume everything is good.

      Here's two examples of the garbage packets being received:

      0;255;3;0;9;TSF:MSG:READ,11-47-153,s=240,c=4,t=205,pt=6,l=22,sg=0:A4709004C242000524F00D0381C00057D048B18C0808
      0;255;3;0;9;!TSF:MSG:LEN,59!=29
      0;255;3;0;9;TSM:READY:NWD REQ
      0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
      0;255;3;0;9;TSF:SAN:OK
      
      0;255;3;0;9;TSF:MSG:READ,144-0-0,s=160,c=5,t=0,pt=5,l=0,sg=1:117440612
      0;255;3;0;9;!TSF:MSG:LEN,61!=32
      0;255;3;0;9;TSF:SAN:OK
      0;255;3;0;9;TSM:READY:NWD REQ
      0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
      0;255;3;0;9;TSF:SAN:OK
      

      The NWD - MSG SEND - SAN OK cycle repeats continuously thereafter, sometimes punctuated by attempts from the controller to send commands which never get out as such:

      0;255;3;0;9;Message arrived on topic: sensors-in/2/4/1/0/2
      0;255;3;0;9;!TSF:MSG:SEND,0-0-2-2,s=4,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:0
      0;255;3;0;9;TSM:READY:NWD REQ
      0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
      0;255;3;0;9;TSF:SAN:OK
      

      It looks like the network discovery routine is succeeding, but I never see any activity on the gateway LEDs after the fault occurs so I assume it's returning a successful result without actually interrogating the network at all (maybe that's by design? I haven't gone digging to see).

      The garbage packets could possibly be related to the Oregon Scientific weather station I have on my roof. I believe it communicates using PAM 433MHz and I wouldn't be surprised if it isn't friendly about sharing the spectrum and just talked over the MyS packets. This would fit with the randomness of the failure, since it requires a OS weather sensor to clash with a MyS sensor message. I would've thought (hoped) that the gateway would be able to ignore and recover from such an event though.

      Any thoughts?

      posted in Troubleshooting
      Carywin
      Carywin
    • RE: Remainder sleep time upon an interrupt

      A coarser but library-compatible way of doing it is to keep a variable with your desired sleep time in it. Each time you wake up from sleep you test if the wake up was caused by interrupt or by the sleep time completing. If it was an interrupt, halve the value of your sleep time variable and call sleep again with the new value. If it was by sleep time expiring, reset your sleep time variable to your desired interval.

      Here's a snippet from a recent sketch where I faced this issue:

      if(sleep(1, CHANGE, (uint32_t)cycleTimer) == MY_WAKE_UP_BY_TIMER) { // Put the CPU to sleep, wake on interrupts
            #ifdef MY_DEBUG
              Serial.println("- Wake From Full Sleep Cycle -");
            #endif
            cycleComplete = true; // Flag that a full sleep cycle was completed
          } else {
            cycleTimer /= 2; // If we get woken from normal sleep by interrupt, halve the remaining cycle time
          }
      

      Up in my main loop I use "cycleComplete" to flag that the sleep interval is over and it's time to send some messages, and in that routine "cycleTimer" gets reset to the full interval.

      posted in Development
      Carywin
      Carywin
    • RE: is mesh n/w possible using RFM69 without using gateway?

      Check out the RadioHead library, it implements a mesh network on RFM69

      posted in NodeManager
      Carywin
      Carywin
    • RE: 💬 MyMultisensors

      Here's my first 5 multi-sensors assembled and they've passed simple hardware tests. Although I think I have 2 that have PIRs that won't settle down. Thanks for the design scalz!
      0_1500541753297_Photo 20-7-17, 16 56 10.jpg
      Now to write some firmware for them... Any hints?

      posted in OpenHardware.io
      Carywin
      Carywin
    • RE: RFM69 + RS485 Sensor Network Question

      Thanks for the responses. I guess I'll try a simple RFM repeater up there instead, and wait to see if bridging becomes available.

      posted in Hardware
      Carywin
      Carywin

    Latest posts made by Carywin

    • RE: is mesh n/w possible using RFM69 without using gateway?

      Check out the RadioHead library, it implements a mesh network on RFM69

      posted in NodeManager
      Carywin
      Carywin
    • RE: Ethernet/WiFi-Client Gateway

      If you’re using sensors over wifi you don’t need MySensors, you can just use PubSubClient. MySensors is primarily for mesh network sensors not using wifi.

      posted in Troubleshooting
      Carywin
      Carywin
    • RE: Want Wired Ethernet For All Sensor Nodes / Gateway

      You don’t need MySensors for this, PubSubClient will do what you need.

      posted in General Discussion
      Carywin
      Carywin
    • RE: Using an 802.11g wifi transport

      What you need is an MQTT broker and the PubSubClient library. MySensors is not useful to you.

      posted in MyController.org
      Carywin
      Carywin
    • RE: Leonardo/RFM69HW ethernet gateway not working

      I got this working here: https://forum.mysensors.org/topic/6249/mqtt-ethernet-gateway-using-leonardo-32u4-w5100-rfm69h-hard-spi

      posted in Troubleshooting
      Carywin
      Carywin
    • RE: I need some help about sensors

      I have used VL53L0X laser time-of-flight sensors for things like this. They work great, are inexpensive, and reliable. They're available for a few dollars from the usual Chinese suppliers.

      posted in Hardware
      Carywin
      Carywin
    • RE: RFM69HW 868MHz working on 915MHz

      I accidentally used a 915 MHz part at 433 MHz and even that worked, albeit at substantially reduced range.

      posted in Hardware
      Carywin
      Carywin
    • RS485 Baud Rate Errors - Mixing HWSerial Devices Can Cause Problems

      Hi Folks,
      This is more of a troubleshooting report than a request for help. I thought I'd report my findings here in hopes of saving someone else the headaches I've had recently.

      What it boils down to is: the default clocks used on the common 3V3 and 5V Arduino boards cause small errors in actual baud rate on the hardware USART serial ports, and at certain rates the error difference between the two variants is opposite and results in no communications being possible between them.

      Some background:
      I have a small but growing RS485 MySensors network incorporated into my OpenHAB-based home automation system. It started out with just a MQTT gateway and a single node, being a weather station mounted up on the roof about 5 metres away. RS485 was chosen because getting RF signals through the metal roof was problematic, and I was sick of climbing up there to change batteries. Both the gateway and the WXS were built with 3V3 8MHz 32u4 based Arduinos, because then I could use the hardware USART port for RS485 comms while still having the USB port for debugging. Cat-6 cable was used, with one pair for the RS485 comms and a pair each for +12V and GND. The baud rate was set at 115200 bps and this setup worked flawlessly for about a year.
      So pleased was I with the reliability, that I decided all sensor nodes on my upper storey that had easy access for a cable would be wired nodes on the RS485 network going forward.
      The second node to be deployed on the network was a light/heat/fan controller for the bathroom. This node used a 5V 16MHz 32u4 Arduino. When built and tested on the bench, this node worked perfectly; but when deployed into the roof space and connected to mains power it flatly refused to work, spitting FPAR:NOREPLY errors forever. I spent a lot of time trying to troubleshoot the comms issues by investigating ground loops or other noise, termination, or power supply issues. I pulled the AC/DC supply off it and used the central +12V one. I changed the baud rates around and got some intermittent success. At one point I even fried both the Arduino and my laptop when some stray high-power-switching surges tried to find their way to ground through the USB cable. Nothing seemed to work in the roof, everything worked fine on the bench.

      After much longer scratching my head than I feel comfortable admitting I examined the differences between the MQTT gateway and my test setup, investigated how the oscillator clock is divided down to determine the baud rate, and stumbled upon the answer:

      at fosc = 8 MHz (3V3 parts), 115.2kbps, Error = -3.5%
      at fosc = 16 MHz (5V parts), 115.2kbps, Error = 2.1%
      Total error: 5.6%, somewhat outside the tolerable window of ~5% for baud rate error.

      In the end the solution was as simple as lowering the baud rate on the 5V 16MHz part by ~4% to 110600 bps. The new node then instantly connected and has been reliable ever since.

      posted in Troubleshooting
      Carywin
      Carywin
    • RE: 💬 RS485

      This is great, thanks!
      One suggestion: add a switch mode regulator that can handle 12 or 24 volt DC input. This will allow small sensor devices to hang off a typical bus network having extra pairs for the central power supply.

      posted in OpenHardware.io
      Carywin
      Carywin
    • RE: LAN connected MQTT nodes

      You don’t need MySensors for a direct connection to MQTT. Just use pubsubclient.

      posted in Development
      Carywin
      Carywin