Several people have requested the IR Blaster that I demonstrated in this this Luminara Candle Actuator post but the 1st generation IR Blaster is tedious to build by hand so I decided to develop a purpose-built IR Blaster Actuator. The concept is to collapse everything from the 1st generation IR blaster down to a single PCB that also incorporates all the MySensor's capabilities (e.g. OTA sketch updates and hardware message-signing), add a temperature and humidity sensor (why not?), and a high-luminance, long-range IR Blaster all powered by a standard 5VDC AC power adapter. The IR Blaster can be used to control multiple devices in your home that use a standard infrared remote control (e.g. TV, Receiver, DVR, Air Conditioner, Luminara candles, etc.). Below is an overview, the initial schematic and a rough board layout to give you a sense of the design and size. In discussing with @Hek, if there is enough interest, we will offer this board on ITead Studio so if you are interested, please weigh in and more importantly blast away (pun intended) with critiques or flaws in the features, design, etc.

MySensors Core (derivative work of @tobowmo's Sensebender Micro who deserves a ton of credit and huge thanks for this circuit!)

• ATMEL MCU - ATMEGA 328P / Arduino compatible
• Hardware encryption for message signing - ATSHA204A (thanks to @Anticimex for developing the message signing support)
• Flash for OTA sketch updates - AT25F512C (thanks to @tosa and @tekka for the OTA sketch support)
• Radio - NRF24L01+ socket
• 3.3 VDC on-board LDO voltage regulator to power MySensors MCU & Radio Core

Actuators

• High-Luminance IR Blaster (5 IR LEDs)
• Driven by logic-level MOSFET for maximum current distribution to IR LEDs
• Separate 5.0 VDC on-board LDO voltage regulator to power IR blaster (Isolate MySensors Core from IR current dips)
• 180 degree illumination

Sensors

• IR receiver socket (can be used for IR decoding for sketch customization)
• Temperature and Humidity (Si7021 - same sensor that Thomas Mørch selected for the Sense-Bender Micro)

3 Analog Inputs

• A0, A1, A2 (auxiliary input for other sensors - e.g. PIR, luminance, etc.)

Other

• Rx, Tx, and Err LEDs (credit to @thozza for adding LED support to sensors/actuators)

Power

• list itemStandard 5VDC adapter (regulated on board to 3.3V)

Open questions

• IR LED choice - range versus luminance spread (IR-333-A vs. IR-333-C or hybrid)
• Include an external oscillator/crystal
• Decoupling capacitor value for NRF24L01+
• Include barrel connector to simultaneously drive external IR LED emitters
• Physical learn-mode trigger
• (added) Driving 5 IR LEDs at maximum luminance with a single transistor (will breadboard to confirm)
• (added) Include a 5V power plane

So, my wife loves her Luminara candles that she can turn on and off with a Luminara remote control so heck, why not tie them into the HA system so they come on at sunset and go off when we go to bed each evening? I built a high-power IR blaster, ginned up a small circuit to decode the Luminara remote control codes using the IRSensor sketch MySensors example provided by @hek, configured the on/off IR codes in the actuator sketch and voila - our Vera 3 is able to control my wife's candles! Video, photos and the sketch are provided below.

IR Switch Video

Completed IR Switch Actuator

IR Switch Actuator Circuit (top)

IR Switch Actuator Circuit (bottom) - should probably invest in the convenience boards that others have created to avoid excessive wire-wrapping and soldering

Assembling the IR Blaster - parallel circuit, no forward current resistors to maximize radiant luminance.

Assembled IR Blaster (top)

Assembled IR Blaster (bottom)

IR Switch Sketch

This was a fun project with a very positive wife factor and I hope others find this useful.

Cheers.

UPDATE (2015-MAY-13) I have started a new thread here to flesh out the design of an official IR Blaster -

@Jaime-Machado said in Problem Connecting to gateway:

Can anyone tell me whats wrong here?

Welcome to MySensors! Sounds like you are making great strides already. Usually the gateway is connected to an HA controller that is responsible for vending IDs to nodes during the inclusion/pairing process. In your case, if you are using a stand-alone gateway and node, then you will need to statically define the node id in the node sketch. The node id needs to be unique to each node and ranges from 1 to 254 (note, you can also have up to 254 child sensors per node).

Try setting the following in the top of your node sketch before the MySensors.h include.

#define MY_NODE_ID 1

#include <MySensors.h>

Whenever I need to statically set a node id, I usually do so at the very top of the sketch so it is clear when you open the sketch that the node id is statically defined.

Finally, did you know that you can post code blocks using ``` before and after the code to make it more legible? That is what I used above.

Here are some of the results that I achieved with a built-from-scratch reflow oven and Peter's ControLeo.

MySensors.org Dual Channel LED Strip PWD Dimmer with current sensing (voltage, amperes with computed wattage):

Proto-boards from OSHPark

Oven build images...

First board baking...

Temperature profile I achieved for first board.

Fully functional test board.

This final product will be refined and will vary slightly but @hek, @axillent and I plan to make boards like this and more available, once the designs are fully baked so to speak. In the mean time, these simple reflow ovens based upon the ControLeo work very well.

First Dev Boards Complete 10-JUL-2015 - status update with video

I assembled two dev boards yesterday, brought up all subsystems and they are both working great. Still a bit more work to do before they go to production but here are a couple of photos and a demonstration video.

Assembled dev board w/o radio

Assembled board w/Radio attached

Demonstration Video
https://youtu.be/UXjcwlJOMOI

I am going to rev the board a bit to pull all components to the top-side to reduce the cost and also subject the boards to the IR Sensor Array testing to tune the IR LED component choice for maximum performance.

@derksuh Ok, I took a shot at refactoring your sketch. I didn't have much time and I only ensured that it compiles so your MMV... This could probably be simplified even more but you know the old saying, "If I had more time, I would write less code"

#define MY_DEBUG
#define MY_RADIO_NRF24
#define MY_REPEATER_FEATURE
#define MY_NODE_ID 1
 
#include <SPI.h>
#include <MySensors.h>
#include <DHT.h>

// Set this to the pin you connected the DHT's data pin to
#define DHT_DATA_PIN 6

// Set this offset if the sensor has a permanent small offset to the real temperatures
#define SENSOR_TEMP_OFFSET 0

// Sleep time between sensor updates (in milliseconds)
// Must be >1000ms for DHT22 and >2000ms for DHT11
static const uint64_t UPDATE_INTERVAL = 60000;

// Force sending an update of the temperature after n sensor reads, so a controller showing the
// timestamp of the last update doesn't show something like 3 hours in the unlikely case, that
// the value didn't change since;
// i.e. the sensor would force sending an update every UPDATE_INTERVAL*FORCE_UPDATE_N_READS [ms]
static const uint8_t FORCE_UPDATE_N_READS = 10;

#define CHILD_ID_HUM 0
#define CHILD_ID_TEMP 1
#define CHILD_ID_RLAY 2

#define RELAY_PIN  3
#define RELAY_ON 1  
#define RELAY_OFF 0

#define TEMP 0
#define HUMI 1

byte state = 0;
bool metric = true;

MyMessage msgHum(CHILD_ID_HUM, V_HUM);
MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);
MyMessage msgRlay(CHILD_ID_RLAY, V_STATUS);

typedef struct {
  float last;
  uint8_t nNoUpdates;
} sensorState_t;

sensorState_t dhtState[2];

DHT dht;

void presentation()   
{ 
  // Send the sketch version information to the gateway
  sendSketchInfo("TempHumidRelay", "1.1");
  
  // Register all sensors to gw (they will be created as child devices)
  present(CHILD_ID_HUM, S_HUM);
  present(CHILD_ID_TEMP, S_TEMP);
  present(CHILD_ID_RLAY, S_BINARY);

  // Ask the gateway for the units of measure to use
  metric = getConfig().isMetric;
}

void setup()
{
  // Make sure relays are off when starting up
  pinMode(RELAY_PIN, OUTPUT);
  digitalWrite(RELAY_PIN, RELAY_OFF);

  // Initialize the Temperature & Humidity sensor, first reading will be sent from loop()
  if (UPDATE_INTERVAL >= dht.getMinimumSamplingPeriod()) {
    dht.setup(DHT_DATA_PIN); // set data pin of DHT sensor and model (e.g. DHT_22, DHT_11)
  } else {
    Serial.println("Warning: UPDATE_INTERVAL is smaller than supported by the sensor!");
    Serial.println("Increase UPDATE_INTERVAL and re-upload sketch...");
  }
 
  // Request the latest relay status from the gateway 
  Serial.println("Requesting initial value from controller");
  request(CHILD_ID_RLAY, V_STATUS);
}

void loop()      
{ 
  // Sleep until next valid interal to read temperature and humidity
  wait(UPDATE_INTERVAL);

  // Read current temperature & humidity from DHT22
  dht.readSensor(true);
  float temperature = dht.getTemperature();

  // Only send temperature if it has changed since the last measurement or if we didn't send an update for n times
  if (temperature != dhtState[TEMP].last || dhtState[TEMP].nNoUpdates >= FORCE_UPDATE_N_READS) {
    dhtState[TEMP].last = temperature;
    temperature = metric ? temperature : dht.toFahrenheit(temperature);
    temperature += SENSOR_TEMP_OFFSET;
    send(msgTemp.set(temperature, 1));
    #ifdef MY_DEBUG
      Serial.print("T: ");
      Serial.println(temperature);
    #endif
    dhtState[TEMP].nNoUpdates = 0;
  }
  else if (isnan(temperature)) {
    Serial.println("Failed reading temperature from DHT!");
  } else {
    // Increase no update counter if the temperature stayed the same
    dhtState[TEMP].nNoUpdates++;
  }

  // Retrieve the current humidity
  float humidity = dht.getHumidity();

  // Only send humidity if it changed since the last measurement or if we didn't send an update for n times
  if (humidity != dhtState[HUMI].last || dhtState[HUMI].nNoUpdates >= FORCE_UPDATE_N_READS) {
    dhtState[HUMI].last = humidity;
    send(msgHum.set(humidity, 1));
    
    #ifdef MY_DEBUG
      Serial.print("H: ");
      Serial.println(humidity);
    #endif
    dhtState[HUMI].nNoUpdates = 0;

  } else if (isnan(humidity)) {
    Serial.println("Failed reading humidity from DHT");
  } else {
    // Increase no update counter if the humidity stayed the same
    dhtState[HUMI].nNoUpdates++;
  }
}

void receive(const MyMessage &message) {
  Serial.println("Received message...");

  if (message.type == V_STATUS) {
    // Change relay state
    state = message.getByte();
    digitalWrite(RELAY_PIN, state);
    send(msgRlay.set(state));
  }
}

@gloob, @john, @notYetRated and everyone else - Here is an update on IR Blaster project

The first dev boards are working well but not as good as they should IMHO. My 0.5 LED circuit design uses a separate voltage-regulated parallel IR LED emitter circuit. After a lot of technical research into the depths of IR Emitters and collaboration with others, I can greatly improve the IR performance by moving to a constant-current (not constant-voltage) serial IR LED emitter circuit. I have been scouring the net for constant current regulators and/or LED drivers that can handle 7 IR LEDs @100ma & 1.6FV and have a few candidates under review for prototyping.

I have also been in touch with the AnalysisIR guys to ensure compatibility of our board with their offerings because users have successfully decoded long IR encodings, using the advanced AnalysisIR decoding software, such as HVAC units popular in the EU/UK - for example Panasonic AC and Mitsubishi AC. The goal being that any Analysis IR decodes, will be directly compatible with our board so we can leverage the enthusiasm and prior work of the AnalysisIR community at large. In addition, I would like to advance our board to be able serve as a full spectrum IR decoder to ensure maximum decoding performance when using AnalysisIR on the board. Compatibility requires running the MCU at 16MHz or great to improve the IR mark/space decoding which also requires additional changes to the original circuit design.

All of that said, the reason for the recent silence by me has been due to my personal life - I have had a hectic family pursuit requiring multi-month travel from home and work has heated up again.

Fear not though, this is an extremely important project for me and I will get it done! While it is taking a bit longer than I had hoped, I firmly believe it will be well worth the wait.

Apologies everyone but progress has been much slower than I had planned/wished for two reasons. 1) Work obligations and 2) a special automation from my wife that has usurped my MySensors cycles that required helping the FreeCAD open source project to advance my cause. My plan is to hit IR Blaster hard within the next 4-6 weeks.

@axillent - Nice to see you here again! Well done

@tmaster The OpenHab website has some info about zwave shield(s) and Fibraro device compatibility here https://docs.openhab.org/addons/bindings/zwave1/readme.html#fibaro-door-contact-fgk-101

@tmaster You'll probably have better luck posting to the Vera forums or sending an email to support@getvera.com.

Also, depending upon your z-wave nodes, you may find that the z-wave shield doesn't work reliably with all nodes because it uses a reverse-engineered protocol with known limitations to avoid licensing issues.

FreeCAD is a leading contender too - opensource (like mySensors and KiCAD), with a very active development community, forums and workbenches for almost any problem domain. It runs on Windows, Linux and macOS and I use it for all my 3D printing needs using a LulzBot 3D printer. The path workbench (for CNC machines) is one of the most dominant areas of development right now and is very mature. The developers are very responsive in the forums and on Gitter along with a lot of community members who constantly help newcomers and seasoned professionals use the product proficiently. It has a built-in python interpreter making it very easy to extend ranging from macros/scripts, community developed add-ons to workbenches for various domains such as stress analysis. FreeCAD is also the basis for the 3D parts/models for KiCAD.

The nice thing about opensource is that the models can be shared freely and openly and if you want to understand how something works or you even want to improve it, you can engage the developers and/or submit a pull request on GitHub.

@signal15 Sorry for your significant meat loss.

You might want to take a look at the TempLeakSensor device luup files on the Vera for ideas. They declare a security device that can be armed/disarmed and associated temp and water events used to detect a freeze or leak respectively. In your case, you would create a TempSensor device that could be armed and disarmed and define a custom variable for that device that defines the trip temperature. Whenever the luup temp variable for that device is modified using the vera UI, you would send the updated trigger temp to the sensor node.

The advantage of this approach is that you can use your TempSensor to trigger scenes when armed (e.g. freezer door is closed) and the current temp exceeds the trigger temp akin to how motion sensors are used. In addition, it would act as a normal temp sensor reporting the current temperature to your vera that you could plot over time to check your freezer performance/efficiency.

@AffordableTech said in Issue after updating from 1.5 to 2.1.1:

Hi @tekka ,

When you say "describe your HW setup", I'm not quite sure what your require? Do you need the specific configuration/wiring of the various eleven nodes, or are your referring to the development PC which the Arduino IDE is running on?

Paul, @tekka was asking about your node h/w configuration; in particular how the radio is wired. The Arduino IDE and Boards Manager that you are using should be fine.

@kincaidj001 If you use an AVR with a USB Vid/Pid (e.g. Arduino Nano with built-in FTDI), it will automatically recognize the USB port. For Ethernet, it is a non issue because the Vera will not communicate with the gateway over USB/Serial so you can use any board compatible with the W5100 Ethernet module.

That said, I encourage you to simply ask the Vera Support folks to tweak your Vera config to recognize the Moetino Vid/Pid combo. I figured it out for the MySensors SenseBender Gateway on a Vera 3 so I am 100% confident that they can configure it so it will work.

@AffordableTech Which version of the Arduino IDE and AVR Boards version are you using? There have been issues due to a gcc compiler bug that could be worked-around by downgrading the AVR boards version. If you are using the latest Arduino IDE and AVR Boards revision, then that is not your root cause.

@kincaidj001 said in Vera and Moteino USB as Gateway:

usb 2-2: USB disconnect, address 3
usb 2-2: new full speed USB device using rt3883-ohci and address 4
usb 2-2: USB disconnect, address 4
+usb 2-2: new full speed USB device using rt3883-ohci and address 5

If you are adventurous, you need to modify /etc/modules.d/60-usbserial to claim the Moetino USB device during boot up and then configure serproxy.conf to recognize the Moetino VID/PID combo. I would like to provide precise instructions but Vera prefers that their customers ask for help doing this. So, you should send an email to support@getvera.com after configuring remote technical support and they will configure the port for you.

FEB 07, 2017 | 10:53AM PST
Alex Sescu replied:
Hello Bruce.

The fixes are too complex for end-users and we don’t recommend our customers to SSH into their units because any damage done to the units via SSH will void support requests.

You should ask your customers to send us an email to support@getvera.com whenever they >encounter this issue and we will gladly help them.

Thank You.

Regards,

Alex Sescu ▾ Senior Customer Care Advocate
Vera Control, Ltd. ▾ Smarter Home Control
www.getvera.com ▾ support@getvera.com ▾ +1 (866) 966-2272

@fifo

I have pretty much the same setup that works. I am using a Vera Plus with the MySensors Gateway with a WS5100 Ethernet module.

1. It looks like your gateway is crashing/restarting upon message sends and receives - not always but frequently. Each one of these log entries is a restart. You will see the pattern in your Gateway Log

Gateway/node restarts on send/receive are typically due to a radio power supply problem. What type of radio module are you using and how are you powering your radio module?

1. Also, it would be helpful if you can provide the log file from your Vera Plus when you run inclusion. If you ssh into your Vera Plus, you can use tail -f /var/log/cmh/LuaUPnP.log | grep Arduino to capture the log messages from the MySensors plugin. Let's figure out #1 first though because the gateway should never crash and until we solve that, you won't be able to include devices.