Posts made by soward

I've been using a 12V supply and a 5V linear regulator to power a RGBW+W strip and a pro-mini for over a year now. And I use the 3.3v regulator on the mini to drive the radio. No problems and while a buck converter might be more efficient, there's no significant (or even noticeable) heat on the linear regulator and it's a pretty small amount of power in general.

Mostly power. Check how much power the ESP & wifi use vs NRF & atmel. For non-battery things it's probably not much of an issue though.

Also the mesh network and repeaters, again less of an issue if you have solid wifi coverage everywhere you would want a sensor.

There's also a more robust set of libraries and tools for working with various physical sensors on the arduino / atmel side than there is ported to the esp side.

But if you are just embarking on this now, and none of this items are an issue, there might be some logic in going all ESP/WiFi...

Check the power at the radio and make sure it's getting ~3.3v . Are the nanos 5v or 3.3v?

How do you envision the system working?

Were you just thinking that turning the knob would rotate through a pre-built palette of colors, which would be shown on the knob's RGB first then transferred to the final device or something where you could control the mix of RGB by pushing the encoder's button to switch from controlling R, G, and B until you get the desired color on the indicator LED then maybe a double push to transfer it to the final device?

I don't think either would be too difficult, but given the differing methods for specifying a color to the various RGB devices, I'm not sure how accurate the preview color will be on the knob's LED.

The speaker is probably being sent an AC waveform, and the meter is just averaging it out so you see 4.7v. Likewise there may be some DC power from one side of it to gnd all the time since it's able to energize the Arduino.

Best would be to trace the circuit further back and see if there is something else you can tap into ahead of the speaker and it's driver.

If not you might be able to tie the speaker outputs together through a diode and a small resistor ( say 16Ohm ) and hook that to pin 3 -- or not depending on how it's driven. Or you could build a voltage dividing circuit to keep the AC voltage down to ~2v and use an ADC pin to read the waveform being sent to the speaker.

Probably the Vera, could try power cycling it to see if it speeds things up a bit?

Could also ssh in to your vera and run:

tail -f /var/log/cmh/LuaUPnP.log |grep Arduino

Then push the bell and see how long it takes for it to show up in the log. If it show up there quickly, but you don't see the change on the web or other i/f the slowdown is either the vera itself or the system/device doing the display.

I have a doorbell sensor and a trigger which sends a growl notification using the push plugin. The sensor also flashes a bright LED directly.

I just tried 5 doorbell pushes while holding the laptop and phone. One took 4 seconds to hit the log and another couple to hit the phone. All the rest took only around 1 second to hit the log and another 1-2 for the growl notification to hit the phone.

I am using the ESP8266 gateway, and was using an ethernet gateway before that. I originally used the serial gateway, but that was before I had the doorbell sensor.

Dunno if any of that helps though.

Perhaps re-word the last note from:

A user experienced data transfer compare to USB-to-Serial(ttl)<-->MySensors Gateway connection. especially on OTA firmware update. If you think this will cause a problem for you, an ethernet gateway might be a better alternative.

to:

A user notes that data transfer speeds are comparable to that of a USB-to-Serial(ttl)<-->MySensors Gateway connections. If you think this may be an issue for your application (e.g. OTA firmware updates), an ethernet gateway might be a better alternative.

thanx,
JpS

I'd been using the ESP gateway for several weeks, but recently was having trouble adding a new sensor I am developing.

Since the copy of dev I built it with was now out of date, I went ahead and updated... still wasn't working right so while I had the serial link to it I checked and noticed it was crashing and cycling. It would work for hours, until I fired up my new node, then crash about immediately. A few dozen debug(PSTR())'s later, I found a cause.

In core/MySensorsCore.cpp the result of _msg.getConfig() is dereferenced in a comparison, and it's possible it could return NULL ( like when it's a new node ). I put a check around that and it's not crashing anymore. Which is more than what I can say for my new sensor node....

I have not tested this change with an AVR.

I submitted PR 264.

I haven't actually yet tried to run one at lower voltages, but I recall from looking into it a bit that you can't run at 8Mhz below 2.4v. I think 4Mhz was the max at 1.8 (but that's from memory so might check) -- but to do that would require a new crystal. Hence why most often people will jump down to 1Mhz using the internal osc. But at that speed you probably can't do 57600, and will probably want to go lower, 19200 or 9600 or something.

Google should find you some more detailed info, or even just a search on this forum for low power and 1Mhz or similar.

I'll be there at 6. I'll have on jeans and a black shirt with a tiny apple logo on it and maybe a greyish jacket. I'll leave my conference badge on my belt as well for easy identification

@mfalkvidd Thanks for all the tips and suggestions. I'm quite familiar with procrastination myself, and am putting the finishing touches on the material for my talk just now.

I have been told there is some conference-related event every evening and but it's not yet clear if they are strict start-stop things or just drop-in ones. Regardless, the one on wednesday doesn't start until 19:00, so I can be at the Steampunk bar at 18:00. I will PM you my contact info, and if you send me yours I can let you know if there is any last minute change of plans (and visa vera).

-JpS

I got this working on an 0.9 version of the nodeMCU ( the Yellow board ). It has some code upload issues, which are slightly worse on OS X than Linux, but usually a couple of tries with holding down the button as @hek mentioned usually does the trick. I do not have any TCP/IP clients pointed at it currently, but I also get lots of watch dog timer resets, which seem somewhat random, as it will run and log messages for somewhere between 15 mins and 10 hours.

It is just being powered by USB and I have not swapped NRF modules yet, so one of those may likely be the culprit, but just wanted to chime in with a (mostly) successful setup.

thanx

I'm visiting Sweden next week. Specifically Göteborg, for macsysadmin.se. Since it seemed like a fair number of readers of the forum here are from (somewhere in) Sweden, I thought I might ask for any recommendations of things to see, things to do / not do, etc.

And if anyone is in or near center city Göteborg and wanted to meet up at some time and discuss projects, etc. that'd be great too!

I'll be there from mid-afternoon sunday the 27th thru the following friday.

thanx!

The 2550 is pretty old, dates back to the 90s I think. You could pick up a newer panel and IT-100 for not much $ and fit it in place, possibly using the same keypads. The serial protocol is semi-well documented. I'm using an 1832 and IT-100 though the VERA ( plug-in exists ), and it works reasonably well. I do not know if they use the same 4 wire keypad and same protocol, but I think that has been decoded and hacked as well. That all said it might not be a huge amount more work to just try to use the existing sensors with something home-grown and either get rid of the keypads entirely or roll your own there as well.

Maybe you could post your entire sketch here?

Sounds like you might want to use an array. Something like :

 int myVars[] = { 123,456,789 };
 
 for (int i = 0; i < (sizeof(myVars)/sizeof(int)) ; i++) {
     Serial.println(myVars[i]);
 }

should work, though depending on exactly what you want to accomplish, and what controller you are using, etc. there might be some better approach.

I'm using this as a gateway w/ 1.5 also with no issue. I do have the LEDs hooked up as well, using an oversized 'recovered' power supply and the PA+LNA radio with no problems. All I need is a nice case...

I do pretty much this right now with a Yale 'Real Livinig' z-wave keypad lock. It sends an even when a pin code is entered, an 'incorrect pin' code if an invalid one and a 'correct' pin code with the name of the code when a valid one is entered. I can then make as many scenes as I want using the appropriate trigger. Right now I have a couple of lights come on when I enter mine. I have a special one which opens the roll up garage door, and ones for other people send me an alert, etc.

I think one could do probably craft something cheaper that didn't do the door unlocking, but making it weatherproof and damage resistant like the Yale might be more of a challenge.

@hek I have seen it happen once before with them -- wait a few hours, or at most a day and it'll be corrected if history repeats...

I just tried to order something from them and for some reason DHL is now the only available ( US ) shipping option, and it's quite expensive. The sensorbenders I ordered last month were ~$6 shipping, the other components I looked at today via DHL (similar size) were $46, so might be worth holding off a bit until they restore the air-mail option.

@ServiceXp I'm not sure. I looked around for similar devices almost a year ago, and didn't find any consumer grade chargers or monitors which had such, though there were a few commercial devices for the larger flooded cells which appeared to monitor the fluid level somehow. Some even monitored the specific gravity of the electrolyte, but I'm sure those cost more than several 'basement watchdogs.

I suppose I could try to decode the simpler-looking circuit on the 'emergency' model and try to figure out what it was doing, but I think I've forgotten what little I actually learned in Circuits class back in college.

@Moshe-Livne that would be interesting. I've not looked for any cheap IR temp sensors, though I'm sure there must be something. Of course the stove has a 'hot surface' warning LED itself, but that's not as interesting!

After a couple of water incursion events, the house was equipped with a battery powered sump pump. Specifically the Basement Watchdog 'Big Dog' model. This device used a large lead acid solid plate ( deep cycle ) battery, a high power 12V water pump, a float valve and a control/charge system. Both the pump and it's float were mounted a few inches above the standard sump pump, and a separate set of discharge pipes was ran which could dump the excess down the hill out in the front yard.

This system worked well for just short of 10 years, requiring only periodic battery maintenance. Until the control unit failed completely; all LEDs flickering, random beeping sounds. Looking inside the unit I found lots of analog circuitry, and nothing obviously damaged like a bad cap, etc. Battery was good, pump was good, etc. The system cost (not including installation) exceeded $600, so I searched for cheaper options. Basement Watchdog offers several cheaper versions. So I purchased their 'Emergency' version, but retained my existing pump, float and battery. This also worked well for almost 2 years, then its 'battery fail' indicator came on... fair enough, the battery was 12 years old -- though it had probably only cycled 20 times in those 12 years...but sure enough the battery wouldn't hold a charge using an external charger. so I replaced the battery. About 8 months later, another bad battery warning, same deal. And the unit had not been engaged at all over that time. Some reading indicated that the 'Emergency' version had a poorly designed charging circuit, combined with some dodgy wall-wart power supplies, and it was known to kill batteries.

So I decided to build my own, still keeping the original 12V pump and float. The project is pretty simple. There's a 12V deep cycle battery with a 'intelligent 3Amp charger/conditioner' connected to it's main terminals. From the accessory (screw post) terminals hangs my device. The 12V splits inside there going to a relay and to a simple 7805 linear regulator, which powers a 3.3V 8Mhz Pro Mini. The 5v from the 7805 also powers a single relay board, controlled by the Mini. The float is connected from ground to a pin on the mini, and a push-button switch rescued from an old computer is also connected to allow for manual pump/battery testing. Two LEDs indicate that the system is alive, and if the pump is (or at least should be) activated.

From the mySensors standpoint, it just appears as a relay/switch. From there I can use the VERA to alert me when the sump is activated, or potentially use other sensors -- such as the floor water sensor I built a long time ago for the DSC Alarm -- to engage the pump. Or run a periodic pump test, etc.

One thing the BW system had which I'm not sure how to implement was a low-water sensor for the wet cell battery. It was simply a ~5" metal rod which was inserted into one of the cells of the battery via a cap with a tiny hole in it. I'm guessing this was able to produce some amount of micro voltage and when it dropped off past a threshold it meant that it was no longer in contact with enough acid to produce the voltage?

See below for code and pictures. I should probably diagram the circuit as well...

most recent sketch:

// I need two switches for the SUMP. 
//  1> test switch. Momemtary push engages a ~3-5 second run of the sump pump (and signal back to gateway)
//  2> Actual float switch from sump pump... Pump should engage when this switch is on, and disenages when it is off.
//     Very long 'debounce' on the on and off here as the water may have small waves in it...
// And one relay to connect the 12V battery to the 12V sump motor.
// And an LED to display some status...

#include <MySensor.h>
#include <SPI.h>
#include <Bounce2.h>

#define RELAY  5         // Arduino Digital I/O pin number for relay 
#define FLOAT  3         // Arduino Digital I/O pin number for button 
#define TEST_BUTTON 4    // A button to run a sump test.
#define STATUS_ONLINE 6  // Blinking LED to indicate 'OK/READY!' status
#define STATUS_ACTIVE 7  // LED to indicate that the pump is (should be) active
#define CHILD_ID 1       // Id of the sensor child

Bounce floatDebounce = Bounce(); 
Bounce testDebouncer = Bounce();
int oldValue=0;
bool state;

MySensor gw;
MyMessage msg(CHILD_ID,V_LIGHT);

// Consider making this a MOTION also, and float trigger will trip the zone, so other action can take place?
// Though how is this really different that monitoring the switch for ON?
void setup()  
{  
  Serial.begin(115200);
  
  gw.begin( incomingMessage );

  gw.sendSketchInfo("BackupSump", "1.2");

 // Setup the float
  pinMode(FLOAT,INPUT);
  // Activate internal pull-up
  digitalWrite(FLOAT,HIGH);
  
  // After setting up the float, setup debouncer
  floatDebounce.attach(FLOAT);
  floatDebounce.interval(750);
  
  // Do the same for the test button, but with a bit more sensativity
  pinMode(TEST_BUTTON, INPUT);
  digitalWrite(TEST_BUTTON,HIGH);
  testDebouncer.attach(TEST_BUTTON);
  testDebouncer.interval(40);

  // Register mySensors with gateway
  gw.present(CHILD_ID, S_LIGHT);

  pinMode(STATUS_ONLINE, OUTPUT);

  pinMode(STATUS_ACTIVE, OUTPUT);
  digitalWrite(STATUS_ACTIVE,false);  
  
  // Sump off on boot
  digitalWrite(RELAY, false);
  // Then set relay pins in output mode
  pinMode(RELAY, OUTPUT);   
       
  Serial.println("Initialized. Awaiting change");
}

void loop() 
{
  gw.process();
  
  // 'Breathing' online LED indicator, most of the equation from : http://sean.voisen.org/blog/2011/10/breathing-led-with-arduino/
  float val = (exp(sin(millis()/2000.0*PI)) - 0.36787944)*(108.0 * .75);
  analogWrite(STATUS_ONLINE,val);
  
  // Check on the test button
  if (testDebouncer.update()) {
    if (!testDebouncer.read()) { // Test Button pushed, gateway need not know.
      pump_test();
    }
  }
  
  // Check on our float
  if (floatDebounce.update()) {
    int value = floatDebounce.read();
    // 0 == switch grounded (closed), float underwater.
    if (value != oldValue) {
        // Engage pump even if we cannot talk to gateway.
        Serial.print("Switch value is now: ");
        Serial.println(value?"OFF":"ON");
        digitalWrite(RELAY, value?false:true);
        digitalWrite(STATUS_ACTIVE,value?false:true);
        gw.send(msg.set(value?false:true), true); // Send new state and request ack back
    }
    oldValue = value;
  }
} 
 
void incomingMessage(const MyMessage &message) {
     
  if (message.type == V_LIGHT ) {
     // Change relay state
     state = message.getBool();
     digitalWrite(RELAY, state?true:false);
     digitalWrite(STATUS_ACTIVE,state?true:false);     
   } 
}

// Run the pump for about 5 seconds
void pump_test() {
  Serial.println("Pump test Engaged.");
  gw.send(msg.set(true), true); // Send new state and request ack back

  digitalWrite(STATUS_ONLINE,false);
  digitalWrite(RELAY,true);
  digitalWrite(STATUS_ACTIVE,true);
  
  delay(5000);
  
  digitalWrite(RELAY,false);
  digitalWrite(STATUS_ACTIVE,false);
  
  gw.send(msg.set(false), true); // Send new state and request ack back
  Serial.println("Pump test complete.");
}

Pics --

Unit in case and connected to battery, pump, and float (temporary location)

Case open, parts hanging out:

Close up of regulator and relay:

@Hoffan Sure here's a few:
Breadboard on top of cabinet:

Controls sample in HomeWave iOS App:

Green and Stove strip on:

All Whites on (Stove strip is 'warm white' ~3K):

Hack Job under cabinet mounting and wiring:

Purple:

I agree with @sparkman, swapping that out for a semi-modern DSC will allow you to easily connect it to the VERA and use the existing sensors in scenes, as alerts/alarms, etc for not a whole lot of work or $, and maintain a traditional keypad/panel, especially if you sell the house one day. The DSC stuff is pretty well documented and easy to work with, and available cheaply on Ebay and other places. It can be a bit fiddly and you will probably need a WinXX box to program it ( though it can all be done via the keypad as well )

Using a RGBW LED strip, I put over & under cabinet lights in the kitchen, but I wanted some more direct white light right over the stove, so I added an additional white strip there. I also wanted to be able to control it manually, so I tied in a rotary encoder with push-button switch.

All 5 (RGBWW) are controllable as separate dimmable lights via mySensors + VERA as usual. The final W tied to the encoder can have it's illumination increased/decreased by a turn of the knob, and updates mySensors/VERA on change. Pushing the button will turn off the strip completely if it is on, and restore it to the last known brightness value if it is off.

Presently it is still on a breadboard while I find the time to master Kicad, or decide that will never happen and solder it together on a perfboard. I am using an external 12V CC supply feeding both a pro mini and 5 MOSFETs to drive the LED strips. It has been running for about 7 months now -- since the breadboard sits on the back top of the cabinets, it provides a low incentive to reconfigure the hardware.

Most recent sketch:

/***
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * version 2 as published by the Free Software Foundation.
 * 
 * DESCRIPTION
 * This sketch provides 4 channels of Dimmable LED Lights using PWM for the MySensors.org project
 * Inspired by the PWM example sketcy by <henrik.ekblad@gmail.com> and Bruce Lacey.
 * 
 * REVISION HISTORY
 * Version 0.1 - Sept 5, 2014 John Soward <soward@soward.net>  -- Initial implementation based on example scripts.
 * Version 0.2 - Sept 7, 2014 --  <soward@soward.net> -- Adjust Timer resolution, neaten up, separate debugging output 
 * Version 0.3 - July 5, 2015 --  <soward@soward.net> Pin changes, use Bounce2, update encoder state when brightness changed via mySensors net
 *
 ***/
#define DEBUG 0
#define SN "RGBWW DIM + ENC"
#define SV "0.3"

#include <Encoder.h>    // Using https://www.pjrc.com/teensy/arduino_libraries/Encoder.zip
#include <Bounce2.h>     
#include <MySensor.h> 
#include <SPI.h>

// Ardunio pro mini's have PWM only on 3,5,6,9,10,11
// See http://arduino.cc/en/Main/ArduinoBoardProMini
#define RED 3      // Arduino pin attached to MOSFET Gate pin
#define GREEN 5
#define BLUE 6
#define WHT 9
#define WHT2 10    //WHT2 is a pure white strip, distinct from the RGBW strip for over stove use

// Rotary Encoder connections 
// Better response if one or both of the encoder triggers is on an interrupt pin
#define ENC_SWITCH 8
#define ENC_A 2
#define ENC_B A2
#define ENC_SCALE 2.56   // scaling encoder 256 steps to 100%

#define FADE_DELAY 5  // Delay in ms
#define FADE_DELAY_FACTOR 16

// MySenor uses pin 9 for CE by default, , can be changed here.
// Pin 10 used for CS can also be changed.
MySensor gw(4,7);

Encoder myEnc(ENC_A, ENC_B);
Bounce PowerButton = Bounce();

static int levels[5];  // Current dim levels...
MyMessage dimMsgs[5];
MyMessage lightMsgs[5];
int rotValue = 0;   // encoder position (for WHT2)
int lastBrightness; // last 'on' brightness (for WHT2)

void setup()  
{ 
  //Increase Timer frequency to prevent flicker in Pins 5,6 PWM
  // This alters the performance of millis(), micros() & delay() (basically by 1/16) Unless wiring.c is modified.
  // See http://playground.arduino.cc/Main/TimerPWMCheatsheet
  // W/O this change, a low frequency 'beat' or flicker was exhibited when PWM'ing Pin 5 or 6 and another other pin (on Pro Mini 8Mhz clone)
  TCCR0A = _BV(COM0A1) | _BV(COM0B1) | _BV(WGM00);  
  
  pinMode(RED,OUTPUT);
  pinMode(GREEN,OUTPUT);
  pinMode(BLUE,OUTPUT);
  pinMode(WHT,OUTPUT);
  pinMode(WHT2,OUTPUT);
  
  pinMode(ENC_SWITCH,INPUT);
  digitalWrite(ENC_SWITCH,HIGH);
  PowerButton.attach(ENC_SWITCH);
  PowerButton.interval(80);

  // FIXME Mnemonics for the colors/names/locations of the lights could be useful here.
  for (int i = 0; i < 5; i++) {
    dimMsgs[i] = MyMessage(i,V_DIMMER);
    lightMsgs[i] = MyMessage(i,V_LIGHT);
    levels[i] = 20;
  }

  startupDance();
  analogWrite(WHT2,0);

#ifdef DEBUG
  Serial.println( SN ); 
#endif
  gw.begin( incomingMessage );
  
  // Register each color LED Dimmable Light with the gateway
  gw.present( 0, S_DIMMER );
  gw.present( 1, S_DIMMER );
  gw.present( 2, S_DIMMER );
  gw.present( 3, S_DIMMER );
  gw.present( 4, S_DIMMER );
  
  gw.sendSketchInfo(SN, SV);
  // Pull the gateway's current dim level - restore light level upon sendor node power-up
  gw.request( 0, V_DIMMER );
  gw.request( 1, V_DIMMER );
  gw.request( 2, V_DIMMER );
  gw.request( 3, V_DIMMER );
  gw.request( 4, V_DIMMER );
}

void loop() 
{
  
  // Encoder and button handling.
  // In this implemenation the Encoder and button control the 2nd White strip, position 4 in the array of strips)
  // The encoder will brighten/dim the strip from it's current value.
  // The button will turn off the strip if it is on, or return it to it's last known brightness if it is off
  bool needsUpdate = false;
  
  int newRotValue = myEnc.read();
  if (newRotValue != rotValue) { // I guess it really has changed
    Serial.print("Encoder update:");
    Serial.println(newRotValue);
    if (newRotValue > 255 || newRotValue < 0) {
        myEnc.write(rotValue); // Enforce max/min
    } else {
      rotValue = newRotValue;
      needsUpdate = true;
    }   
  }
  
  if (PowerButton.update()) {
    if (!PowerButton.read()) {
      Serial.println("Button pushed");
      Serial.print("lastBrightness: ");Serial.println(lastBrightness);
      Serial.print("rotValue: ");Serial.println(rotValue);
      if (rotValue) { // we are on, need to go off
        lastBrightness = rotValue;
        rotValue = 0;
      } else {
        rotValue = lastBrightness;
      }
      myEnc.write(rotValue);
      needsUpdate = true;    
    }
  }
  
  if (needsUpdate) {
      int normalizedValue = rotValue / ENC_SCALE;
      fadeLEDToLevel(4,normalizedValue,0);
      gw.send(dimMsgs[4].set(normalizedValue));
      gw.send(lightMsgs[4].set(normalizedValue > 0 ? 1 : 0));
  }
  
  // Standard mySensors message processing (no sleep)
  gw.process();
}

void incomingMessage(const MyMessage &message) {
  if (message.type == V_LIGHT || message.type == V_DIMMER) {
        
    //  Retrieve the power or dim level from the incoming request message
    int requestedLevel = atoi( message.data );
    
    // Adjust incoming level if this is a V_LIGHT variable update [0 == off, 1 == on]
    requestedLevel *= ( message.type == V_LIGHT ? 100 : 1 );
    
    // Clip incoming level to valid range of 0 to 100
    requestedLevel = requestedLevel > 100 ? 100 : requestedLevel;
    requestedLevel = requestedLevel < 0   ? 0   : requestedLevel;
    
#ifdef DEBUG
    Serial.print( "On child id ");
    Serial.print(message.sensor);
    Serial.print( " Changing level to " );
    Serial.print( requestedLevel );
    Serial.print( ", from " ); 
    Serial.println( levels[message.sensor]);
#endif

    fadeLEDToLevel( message.sensor,requestedLevel,FADE_DELAY*FADE_DELAY_FACTOR );
    
    // Sensor 4 is the strip attached the the encoder, update the encoders value, using the scaling factor
    // FIXME Mnemonics might make this more readable/extensible. 
    if (message.sensor == 4) {
        myEnc.write(requestedLevel*ENC_SCALE);
    }  
    
    // Inform the gateway of the current DimmableLED's SwitchPower1 and LoadLevelStatus value...
    gw.send(lightMsgs[message.sensor].set(levels[message.sensor] > 0 ? 1 : 0));

    // hek comment: Is this really nessesary?
    // soward: Probably not, unless there exists some reason why the requested value does not equal
    // the set value 
    gw.send( dimMsgs[message.sensor].set(levels[message.sensor]) );

    }
}

void startupDance() {
  int i,j;
  
// Bring each color up and down independently
   for (i=0;i<5;i++) {
     fadeLEDToLevel(i,100,1);
     delay(50*FADE_DELAY_FACTOR);
     fadeLEDToLevel(i,0,1);
   }
  
 //Bringing each color up sequentially, then back down to 2
  for (i=0;i<5;i++) {
   fadeLEDToLevel(i,100,1);
  }
  delay(50*FADE_DELAY_FACTOR);
  for (i=0;i<5;i++) {
    fadeLEDToLevel(i,2,1);
  }
}

// Helper function to map controller pins to names for strips
int pinForID(int ledID) {
  switch (ledID) {
     case 0: return RED;
     case 1: return GREEN;
     case 2: return BLUE;
     case 3: return WHT;
     case 4: return WHT2;
     return 0; // Default to Red
  }
}

/***
 *  This method provides a graceful fade up/down effect
 */
void fadeLEDToLevel( int theLED, int toLevel, int wait ) {
    
  int delta = ( toLevel - levels[theLED] ) < 0 ? -1 : 1;
    
  while ( levels[theLED] != toLevel ) {
    levels[theLED] += delta;
    analogWrite( pinForID(theLED), (int)(levels[theLED] / 100. * 255) );
    delay( wait );
  }
}

Once connected to the Vera, commands should propagate fairly rapidly. Even 'virtual' commands which are actually scenes that perform complex multi-device actions typically take < 1 second.

However the initial connection to the device from an App or service can take quite some time, and can, as you saw, sometimes simply not work.

For this reason, and because not everyone has said Apps on their devices, I have a few strategically placed Z-wave table-top remotes configured such that their programmable buttons can control some key things for which there is no matching physical switch (i.e. garage door, curtains, etc) and to toggle groups of lights (all basement, all outdoor, etc)

dead bug is just a term for soldering together components w/o a breadboard or similar to put them on -- the resulting bits of electronics with wire 'legs' sticking out looks sorta like a dead bug. There's an art to doing it and making it still look nice which I never learned.

A bridge rectifier is a very simply way to convert AC into DC by using 2 (for a 1/2 wave) or 4 (for a full wave) diodes. Wikipedia probably has a better explanation than I could come up with though.

I added the lights as a secondary feature, since sometimes the lag of getting the message out and back to my phone was enough that I could miss someone -- that and I might have the phone on the charger, and not hear it (or be on the phone and not be able to see the message, etc).

regardless, sounds like your bell is a bit easier to work with than mine was.

I'd like to have a camera there as well, but it's going to be a challenge to get one mounted appropriately.

I added a doorbell alert with mySensors back in the fall -- I was going to post the code here, but I seem to have misplaced it. I have a trigger going to the VERA and a mosfet driving a couple of feet of bright LEDs strung over either side of the door frame between the two sides of the basement. These flashes a few times when the bell is rung, and the vera sends me a prowl message as well. I haven't missed any deliveries since adding it.

However, my 1955 era house here in the US uses AC voltage for the doorbell circuit ( it seems most, but not all, here in the US do as well ). Since the actual transformer is in a difficult to access area of the attic ( I think I code violation now ), I tapped into the wires as they run from the door bell button to the actual bell, this line was easily accessible in the unfinished side of the basement.

I just built a small bridge rectifier from 4 diodes 'dead bug' style on the pins of a relay, and covered the whole thing in some shrink. The relay just grounds a pin on a pro-mini. The pro-mini is just powered by a scavanged wall-wart which also provides enough current to flash the LEDs...

@Sparkman great thanx, I do have the bag somewhere in the pile-of-parts-bags. So far I have only used the demo sketch from playingwithfusion, but once it appears to detect something I'll probably use yours as a base and branch out form there. I'm using a Vera so I can try to use VAR_1 as hek suggested.

I put one of these together a short while ago -- just missed a storm rolling though, but another round might come through later. There's a reference in the code to AS3935_CAPACITANCE and a comment suggesting it be set to "THE NUMBER LISTED ON YOUR BOARD", however I'm seeing no number listed on the board. Am I just over looking it or is it something you derive?

thanx,
JpS

The Vera Edge replaces both the Lite and the Vera3. I tried to grab a dozen V3s from a distributor's last stock, but was only able to get a fraction of that. I do not have an Edge yet, but I would guess it will be UI7 or above only.

That sketch only works when the desired output pins are in numerical sequence. Once you need to use a variety of pin numbers in an arbitrary order, you will need to mange them differently.

Using an array as Hek suggested is no doubt your best option.

I think these were covered to some extent in another topic.

I have a couple and have done some basic experimentation. There are some limitations. The power draw can be significant, rendering battery powered sensors using them impractical in most instances.

Not using the gateway and controller and instead communicating directly to a sensor using one is, of course possible, and might be optional in some situations. However, at that point, you aren't really using much or any of the MySensors project, so just build something and go.

I can see using one to make a 'wifi' gateway.

I can also see using one to allow for direct communication with a particular sensor in addition to using the nRF for some very specialized applications -- e.g. an RGBW LED controller, where you want to be able to have it participate in your overall HA setup, but also want a specialized and fast-to-react portable interface for selecting particular complex colors.

And I'm sure not in love with the extended AT command set and serial as the interface either...

Theoretically, if the compiler and other details of the native architecture are worked out over time, the device could be an entire sensor by itself, communicating directly with the gateway via IP. Granted, existing PCBs only have 2 GPIO pins exposed limiting functionality.

I didn't see any other threads with any usable info -- has anyone done anything with the SAM architecture MCUs? Specifically I was looking at using a Teensy 3 as a gateway. Some quick fiddling indicates that several changes will be needed, most notably the mstimer2 stuff. I can mess around with it as time permits, but just didn't want to miss anything or replicate any efforts, etc.

@jocke4u said:

@hek said:

A question for everyone: Is there any Ethernet module working side-by-side with radio without tweaking SPI behavior? The ENC-module requires too much memory and the WizNet has problems hogging SPI.

I bought SunFounder Uno + Ethernet shield and worked out of box
http://www.ebay.com/itm/Sunfounder-UNO-R3-Ethernet-Schild-W5100-Starter-Kit-fur-Arduino-Mega-2560-Nano-/161382223691?pt=Wissenschaftliche_Geräte&hash=item2593214f4b

I got the enc working, but it would hang after some number of hours (usually around 12, but +/- 8). It did not seem to be based on the volume of traffic flowing through it though, so I dunno if it was a similar SPI conflict or a bug in the IP stack.

I ordered the iTead, but it has yet to arrive, instead I ordered the same Sunfounder unit mentioned above, but from Amazon:

http://www.amazon.com/gp/product/B00JB2Z74W/ref=oh_aui_detailpage_o04_s00?ie=UTF8&psc=1

I built it up and added a 16x4 LCD and some code to display the time and the last 3 communications received by the controller. It's been stable and online 24x7 since sunday night. No SPI modifications.

What are you using for the inductor (L1)? The spec sheet indicates that something in the 4.7 microHenries range should work.

While wifi might be overkill for sensor communication, a wifi gateway would be useful. Reading various bits around the net, it kooks like it might be possible to actually re-flash the unit itself and tap into some of the GPIO pins directly, so there's a possibility that the device itself could be the only component in a sensor, that would make it potentially a more attractive option for certain situations.

I just received a few yesterday, but I'm not sure when I'll have enough time to try to get anything working with them.

I'm not sure about that exact model, but the one things the Weller digital units had over the hakkos when I was shopping was auto-power-off, so if that's a concern it might be worthwhile. However, they were quite a bit more $ here in the US anyway. The Hakko 888D can be had for ~$90US if you are patient. I don't remember the 81 even coming up in a search, the lower powered 51 I looked at, but it was in the $140US range with both less power than the Hakko and the non-adjustable WTCPT I have (temp is adjusted by the particular tip that is installed).

That said, the WTCPT is > 15 years old and still working fine, so I don't think you can go wrong with either.

Also, I think the 240V hakko might be more costly than it's 120V cousin, which might level the playing field outside of NA.

I have a weller non-adjustable unit that I used for years, and I recently moved it to the garage and obtained an adjustable temp hakko 888D, it heats up a little quicker than the weller (okay maybe 1/4 the time) and the holder is a bit nicer, but otherwise they both work well and have a variety of swappable tips. Of course, now I'm thinking I might should have gotten something with hot-air rework capabilities, though really I'm probably not steady enough to do too much SMD fiddling.

Seems wise to go with the E-Net gateway straight away, I ran with the serial for several month but E-net has lots of advantages. I had some difficulties with the ENC board locking up. I've been using a UNO w/ 5100 as you have listed for a few days w/o issue.

I recently bought a new vera for our office which came with UI7 instead of UI5, not sure what issues that might present.

does the _ky indicate that you are in Kentucky?

One of the AC current sensors might work to tell you when the light was engaged by one of the other switches? though I have not tried any of them.

I have noticed that my ENC based ethernet gateway seems to lock up periodically (doesn't respond to ping or TCP on port 5003). I thought perhaps this case was overheating it, but now that doesn't seem to be the case. I'll be switching to one of the iBoard whenever it arrives, but had intended on using the ENC for another purpose, but perhaps not now.

I haven't really tested the range explicitly, and really the case is hopefully somewhat temporary. That said, the unit is in the basement and I have a temp sensor in the attic which works fine, and another sensor on the main floor at the other end of the house which also works fine.

Who needs a fancy printed case when you have some an old mouse case, a dremel and some glue

my cheap case

I've looked around for these as well, but couldn't find any and just made my own. Perhaps it's a product opportunity?

If it doesn't get a link light on the device and on the switch/router you plug it into -- something must be wired wrong. Double check all the wires going to the ENC board, starting with the power and ground. If you get a link light, you can try to 'telnet 192.168.178.66 5003' from a Terminal/Shell/Command prompt (dunno if you are on Linux/MacOS/WinXX). If it's working, that should get you connected and you should see commands going to/from the gateway.

IIRC there is a power LED on the ENC board as well that should be on.

Shouldn't need to do any reserving in your DHCP server if it's hardcoded into your sketch.

Leave the UDP defines in, just change the value, the 3 line section should look like:

#define UIP_CONF_UDP 0
#define UIP_CONF_BROADCAST 1
#define UIP_CONF_UDP_CONNS 4

Note that UIP_CONF_UDP is now 0 not one.

FWIW, Replacing the UIPE library with the current version from github and using the current 1.5.7b IDE seems to be working fine for me here.

You will have to edit UIPEthernet/utility/uipethernet-conf.h and change #define UIP_CONF_UDP to be 0 (line 9), or it will not fit in the available memory.

Also remember you will have to restart the IDE after changing the libraries.

I have not had it running very long, but have blasted loads of commands through it and it seems to be stable so far, using it with a current nano and the NRF24L01+PA+LNA radio, powered via USB.

I have the same setup, and it works okay, voltage sits around 3.2ish volts in operation when powered via USB. If your power supply is adequate, perhaps it's just a bad Nano?