void receive(const MyMessage &message)

[skywatch]

If I have a 'while' loop runnig in void loop() - will the void receive(const MyMessage &message) still be called during this time?

Essentially I need something to happen repeatedly unless a button is pressed or an incomming message arrives to stop it.

Any ideas, I am stuck on this for some reason.

[mfalkvidd]

@skywatch MySensors will not be able to process any incoming messages if you are hogging the cpu.

You can call wait() from your while loop to let MySensors do its stuff.

[skywatch]

@mfalkvidd Thanks as ever for the help. So here is my problem and I can't see a way to do it right now.

A roller blind can be commanded to 'go down' either ....
by pressing a 'down' button or ...
by a 'down' command from the controller.

This needs to move the stepper motor until a pre-defined number of steps have occured UNLESS.....
it gets a stop message from the controller or......
the up button is pressed. (this saves having a third button for stop!)..

I have omitted limit switches and timers to make it simple, but I just can't find a way to make it happen - I know it's not impossible, just beyond my imagination right now!

Adding too many wait() cycles in the main loop will slow the motor down and it is slow enough already....Hmmmm.....would it be better to just have an if loop instead of while and let that run?

Or what about putting that pesky 'while' loop within the receive section?

[mfalkvidd]

@skywatch something like this:

#define STOP 0
#define UP 1
#define DOWN 1

byte state = STOP;

void loop(){
  // If button is pressed, set state accordingly
  upButton.update();
  // Get the update value
  if (upButton.read()) {
    if(state == STOP){
      state = UP;
  } else {
    state = STOP // Stop if it was running
  }
  
  switch (state) {
    case STOP:
    // Stop motor
    digitalWrite(motor_pin_up, 0);
    digitalWrite(motor_pin_down, 0);
    break;
    case UP:
    // Start motor up
    digitalWrite(motor_pin_up, 1);
    break;
    case DOWN:
    // Start motor down
    digitalWrite(motor_pin_down, 1);
    break;
  }
}
void receive(){
 // set state to the right value depending on the message from the controller
 if (msg...) state = xxx
}

I don't know how you know for how long you need to run the motor, could you explain that part?

[skywatch]

@mfalkvidd Thanks for the suggestion.

In order to minimise trouble I have a multi approach to detecting if the blind is 'down'.

I can count the number of steps the stepper takes to get from fully 'up' to fully 'down'. This figure I can use in the sketch to see if the number of steps moved == measured steps. That way it should be 'down'.

I can also use a watch to time the motion to get an approximate idea of time of travel. Again, this can be used to act as an indicator that it should have reached it's position and turn off motor just in case.

I will soon add a magnet to the bottom rail of the blind and this too can be detected with reed relay or hall effect chip as up and down 'limit switches' (not really true limit switches I know, but performing the same function as limit switches).

This way I now know that if any one thing fails, the other should still stop the motor turning indefinitly.

Trouble is that steppers require constant commands to go to the next step (hence the while loop) - but then it blocks the receive() from working.

I'l try and understand your soution and see if it will work with what I have.

TsM.

[tommies]

I had problems with incoming messages ans loop.
If you use nrf24 @Yveaux suggested me to use irq to handle incoming messages.
I my case it solved my problem

https://forum.mysensors.org/topic/7190/irq-pin-for-nrf24l01

[skywatch]

@tommies

Thanks for the help but today I think I am nearly there with this. I am on the third version and it looks promising. I hope to test it fully this week and I'll let you (all) know if it works.

[pjr]

How about non blocking interrupt driven stepper library? For example: https://github.com/bjpirt/HotStepper

[skywatch]

@pjr Thanks for the hint.

I believe I have what I need now, will be testing tomorrow I hope.

Essentially I have reduced void loop() and void receive() down to minimum so the program loops very fast. This way it only calls other void () routines as needed.

[skywatch]

@skywatch Hmmmm....It didn't work as I expected.

So if I have a loop with a 'while' routine running, what do I need to do in the 'while' code to check if any messages have arrived?

something ike.....

while (MOVING_UP == true && stepcount < BLIND_UP) {
Do code to turn stepper motor.
Check for radio message.
Act on radio message (if there is one)
Check for button press.
Act on button press (if there is one)
update step count
}

The buttons and motor I have working, its just that radio messages are currently 'blocked' during the while loop and this isn't good if an emergency stop call is required.

[mfalkvidd]

@skywatch I think you're looking for the wait() function. https://www.mysensors.org/download/sensor_api_20#waiting

Or _process() but that's an internal function so it might not be as well documented and might undergo changes that aren't mentioned in release notes in future releases.

[skywatch]

@mfalkvidd I was just about to say something on that! - you just beat me too it!

I understand the wait(), but what I have no clue of is how long should a wait() be to get incomming messages? -- Would wait(25); be enough?

[mfalkvidd]

@skywatch it depends a bit on which platform you are using, the clock speed you are using, how often wait is called, how busy your network is, which transport you are using and how much packet loss you are willing to accept. But 25 should work.

I found transportProcess() which is called without any parameters. You can use that instead.

[skywatch]

@mfalkvidd pro mini @ 16MHz - I didn't mention that as I was looking at it as purely a programming issue....doh!

So are you saying that if I simply put transportProcess() in the while statement it will pause the while loop, check for any messages from the nrf24 and then resume the while loop? Of so, that should work if it is quick.

[Yveaux]

@skywatch said in void receive(const MyMessage &message):

I understand the wait(), but what I have no clue of is how long should a wait() be to get incomming messages? -- Would wait(25); be enough?

Just wait as short as possible, 1ms or even 0 (not sure if that is supported).
It allows the stack to process any queued messages and returns as quickly as possible.
There is no need to wait for a longer time, as radios will queue incoming messages in hardware. The actual number of messages that can be queued depends on the radio used; for nrf24 it is 3.

[skywatch]

@mfalkvidd I tried with transportProcess() and it seemed to work well initially, but then something happened (probably HW related) so it is looking promising.

@Yveaux Thank you for the tip

I will try this next and see how much of a difference it makes -would wait(1); be better in any way to calling transportProcess()?

But at least it looks like the system might operate as I had intended, hurrah!

[Yveaux]

@skywatch said in void receive(const MyMessage &message):

would wait(1); be better in any way to calling transportProcess()?

Definately! transportProcess() is a library internal call, which might change without notice or has side effects one cannot oversee. Wait() is an external api call, which won't change without notice, and is documented.

[skywatch]

@yveaux Thank you for the fast response and explaination. I'll go with what you said!

[mfalkvidd]

There is a slight risk that wait() will return immediately without processing messages, if the parameter is lower than the increment of millis(). The increment of millis() depends on platform and clock speed. I am not sure if this risk is big enough that it needs to be considered.

[skywatch]

Thank you both for the help - much appreciated.

So I went with wait(1); and then only called it every 250 steps as otherwise it was slowing things down too much. It seems pretty reliable at the moment, but I do have dodgy duponts so have to sort them out next!

One thing I do see is this......

352968 !MCO:WAI:RC=3
352971 !MCO:WAI:RC=3
352974 !MCO:WAI:RC=3
352977 !MCO:WAI:RC=3
352980 !MCO:WAI:RC=3
352984 !MCO:WAI:RC=3
352987 !MCO:WAI:RC=3
352990 !MCO:WAI:RC=3

Not always, but sometimes.....what is this trying to tell me and where do I look to fix it - I can post full code if you like, but it's not for the faint of heart;)

[mfalkvidd]

@skywatch those messages mean that wait is being called from within wait. That is usually bad, so MySensors prints a warning message. Could you post your code?

[skywatch]

@mfalkvidd Here is the code - remember it is in development and some things are currently commented out to concentrate on the places where I have issues.

/*
   Solar Powered Roller Blind - Landing

   Pin Assignments..... 5V pro mini

   D2 Down Button.
   D3 Up Button.
   D4,D5,D6,D7 for stepper motor. 12V
   D8 Power fail detect? -and write stepcount to eeprom
   D9,D10,D11,D12,D13 for NRF24L01+. 3.3V
   A0 UP LIMIT magnet sensor.
   A1 DOWN LIMIT magnet sensor.
   A2 Window Sensor.
   A3 FREE
   A4 ATSHA204a.
   A5 Battery Voltage Sensor.
   A6 FREE - input only
   A7 FREE - input only

*/

#define MY_DEBUG
#define MY_RADIO_RF24
#define MY_RF24_PA_LEVEL   RF24_PA_HIGH
#define MY_NODE_ID 181
#define MY_RF24_CHANNEL (97)
#define MY_PARENT_NODE_ID 0
#define MY_PARENT_NODE_IS_STATIC
//#define MY_REPEATER_FEATURE
//#define MY_SIGNING_ATSHA204
//#define MY_SIGNING_REQUEST_SIGNATURES
//#define MY_SIGNING_SOFT
//#define MY_SIGNING_SIMPLE_PASSWD

#include <MySensors.h>
#include <Stepper.h>
#include <Bounce2.h>
// define number of steps per revolution
#define STEPS 32

// define stepper motor control pins
#define IN1   7
#define IN2   6
#define IN3   5
#define IN4   4
#define EEPROM_STEPCOUNT_ADDRESS 0
#define BLIND_UP 39500  //********
#define BLIND_DOWN 100  //********
//#define LIMIT_UP A0
//#define LIMIT_DOWN A1
#define DOWN_BUTTON 2
#define UP_BUTTON 3
#define WINDOW_SENSOR A2
//#define VOLTMETER A5
#define CHILD_ID_LANDING_BLIND 0
//#define CHILD_ID_BATTERY 1
#define CHILD_ID_LANDING_WINDOW 2
#define CHILD_ID_LANDING_ALARM 3

//float battery = 0.0;
//unsigned long BattSendDelay = 10800000;
unsigned long previousMillis = 0;
unsigned long previousButtonMillis = 0;
unsigned long ButtonMillis = 5000;
unsigned long stepcount = BLIND_UP;  //******Blind UP for CAL....
unsigned long laststepcount = BLIND_UP;
unsigned long upspeed = 900;
int upstep = 5;
int downstep = -1;
int oldValue=-1;
bool MOVING_UP = false;
bool MOVING_DOWN = false;
bool ALARM_ARMED = false;
bool ALARM_TRIPPED = false;

Bounce debouncerUP = Bounce();
Bounce debouncerDOWN = Bounce();
Bounce debouncerWINDOW = Bounce();

// initialize stepper library
Stepper stepper(STEPS, IN4, IN2, IN3, IN1);

MyMessage msgB_UP(CHILD_ID_LANDING_BLIND, V_UP);
MyMessage msgB_DOWN(CHILD_ID_LANDING_BLIND, V_DOWN);
MyMessage msgB_STOP(CHILD_ID_LANDING_BLIND, V_STOP);
//MyMessage msgBBattery(CHILD_ID_LANDING_BLIND, V_VOLTAGE);
//MyMessage msgB_PERCENTAGE(CHILD_ID_LANDING_BLIND, V_PERCENTAGE);
MyMessage msgB_ALARM(CHILD_ID_LANDING_WINDOW, V_TRIPPED);
MyMessage msgB_WINDOW(CHILD_ID_LANDING_WINDOW, V_TRIPPED);


void setup()
{
  Serial.begin(115200);
  pinMode(DOWN_BUTTON, INPUT_PULLUP);
  pinMode(UP_BUTTON, INPUT_PULLUP);
  //pinMode(LIMIT_UP, INPUT_PULLUP);
  //pinMode(LIMIT_DOWN, INPUT_PULLUP);
  pinMode(WINDOW_SENSOR, INPUT_PULLUP);
  //pinMode(VOLTMETER, INPUT);
  debouncerUP.attach(UP_BUTTON);
  debouncerUP.interval(25);
  debouncerDOWN.attach(DOWN_BUTTON);
  debouncerDOWN.interval(25);
  debouncerWINDOW.attach(WINDOW_SENSOR);
  debouncerWINDOW.interval(25);
  //**** Comment next line after first upload - inital calibration only....
  hwWriteConfigBlock((void*)&stepcount, (void*)(EEPROM_LOCAL_CONFIG_ADDRESS + EEPROM_STEPCOUNT_ADDRESS), 4); //saveStepcount - Use once to set 'memory'. Then reflash with this commented out.
  hwReadConfigBlock((void*)&stepcount, (void*)(EEPROM_LOCAL_CONFIG_ADDRESS + EEPROM_STEPCOUNT_ADDRESS), 4); // Get from EEPROM last position.
  digitalWrite(IN1, LOW);
  digitalWrite(IN2, LOW);
  digitalWrite(IN3, LOW);
  digitalWrite(IN4, LOW);
}


void presentation()  {
  sendSketchInfo("MYS-Landing Blind", "0.4");
  wait(150);
  present(CHILD_ID_LANDING_BLIND, S_COVER, "Landing-Blind", true);
  // present(CHILD_ID_BATTERY, S_MULTIMETER, "Battery", true);
   wait(200);
   present(CHILD_ID_LANDING_ALARM, S_BINARY, "Landing-Alarm", true);
   wait(200);
   present(CHILD_ID_LANDING_WINDOW, S_BINARY, "Landing-Window", true);
  
    //long batterytemp = (readVcc());
  //float batteryf = (float) batterytemp;
  //battery = batteryf/1000.0;
  //send(msgBBattery.set(battery,2),true);
}

void loop()
{

  // move the blind UP
  debouncerUP.update();
  if (debouncerUP.fell() || MOVING_UP == true) {
    MOVING_UP = true;
    UP();
  }

  // move the blind DOWN
  debouncerDOWN.update();
  if (debouncerDOWN.fell() || MOVING_DOWN == true) {
    MOVING_DOWN = true;
    DOWN();
  }
  
  //Manual calibration call
  if (debouncerUP.fell() && debouncerDOWN.fell()){
    previousButtonMillis = millis();
    while (millis() - previousButtonMillis < ButtonMillis){
      debouncerUP.update();
      debouncerDOWN.update();
      if (debouncerUP.rose() || debouncerDOWN.rose()){
        break;
      }
    }
  }
    else calibrate();
    
  debouncerWINDOW.update();
  if (debouncerWINDOW.rose() && ALARM_ARMED == true){
    send(msgB_ALARM.set(ALARM_TRIPPED = 0), true);
    }
    if (debouncerWINDOW.fell() && ALARM_ARMED == true){
    send(msgB_ALARM.set(ALARM_TRIPPED = 1), true);
    }
//    debouncer.update();
  
  // Send window update...
  int value = debouncerWINDOW.read();
  if (value != oldValue) {
     // Send in the new value
     send(msgB_WINDOW.set(value==HIGH ? 1 : 0));
     oldValue = value;
  }

  //Read and send battery every 3 hours
  /* if (millis() - previousMillis >= BattSendDelay) {
     previousMillis = millis();
     long batterytemp = (readVcc());
     float batteryf = (float) batterytemp;
     battery = batteryf/1000.0;
     //float batteryraw = digitalRead(VOLTMETER);
     //add calibration here.....
     send(msgBBattery.set(battery,2),true);
    }*/
  //!!!!!  NO SLEEPING !!!!!  ;)

}

void receive(const MyMessage &message) {

  // STOP - if message == V_STOP, stop blinds immediately.
  if (message.type == V_STOP) {
    stop();
  }

  // UP - if message == V_UP call void UP()
  if (message.type == V_UP) {
    MOVING_UP = true;
    UP();
  }

  // DOWN - if message == V_DOWN call void DOWN()
  if (message.type == V_DOWN) {
    MOVING_DOWN = true;
    DOWN();
  }

  //Add if (message.type==V_PERCENTAGE); and add calculation....maybe?
  // for reference 1% == 395 steps....
}

void stop()
{
  digitalWrite(IN1, LOW);
  digitalWrite(IN2, LOW);
  digitalWrite(IN3, LOW);
  digitalWrite(IN4, LOW);
  send(msgB_STOP.set(stepcount), true);
  MOVING_UP = false;
  MOVING_DOWN = false;
  hwWriteConfigBlock((void*)&stepcount, (void*)(EEPROM_LOCAL_CONFIG_ADDRESS + EEPROM_STEPCOUNT_ADDRESS), 4);
  wait(100);
}

void UP()
{
  //If already in motion then stop and reverse direction.
  if (MOVING_DOWN == true) {
    stop();
    MOVING_UP = true;
  }

   // test if already up here!!!! - if not recall stepcount and calulate number of steps required.
  while (MOVING_UP == true && stepcount < BLIND_UP) { //&& LIMIT_UP == HIGH)
    // set motor speed 
    if (stepcount >= 20000) {
       upspeed = 1000;
    }
    if (stepcount >= (BLIND_UP - 50)) {
       upstep = 1;
    }
    stepper.setSpeed(upspeed); //higher speed = lower torque...
    // move the motor (x steps)
    stepper.step(upstep);
    stepcount = stepcount + upstep;
   // Serial.println("UP-StepCount = " + (String)stepcount);
    // }

    //Test if manual stop.
    debouncerDOWN.update();
    if (debouncerDOWN.fell()) {
      stop();
    }

    //Add time limit for safety?
    //up timeout message?

    //Test if at end of travel.
    if (stepcount == BLIND_UP) {   // || digitalRead(LIMIT_UP) == LOW)
      stop();
      downstep = -1;
      break;
    }

    //Check for incomming radio message at frequent intervals.
    if(stepcount > laststepcount + 500){
      laststepcount = stepcount;
      wait(1); //allows RX function.
   }
 }
}

void DOWN()
{
  //If already in motion then stop and reverse direction.
  if (MOVING_UP == true) {
    stop();
    MOVING_DOWN = true;
  }

   //Check if window open
   debouncerWINDOW.update();
    
  //Do not close if window is open or already closed.
  while (MOVING_DOWN == true && stepcount > BLIND_DOWN && debouncerWINDOW.read() == LOW)// && digitalRead(WINDOW_SENSOR) == LOW && LIMIT_DOWN == HIGH)
  {
    stepper.setSpeed(1200); //higher speed = lower torque...
    if (stepcount <= (BLIND_UP-500) && stepcount > 150) {
       downstep = -5;
    }
    if (stepcount <= 150) {
       downstep = -1;
    }
    // move the motor (x steps)
    stepper.step(downstep);
    stepcount = stepcount + downstep;
    //Serial.println("DOWN-StepCount = " + (String)stepcount);
    //}

    //Test if manual stop.
    debouncerUP.update();
    if (debouncerUP.fell()) {
    stop();
    }

    //Test if at end of travel.
    if (stepcount == BLIND_DOWN) { // || digitalRead(LIMIT_DOWN) == LOW) -- maybe add timer as well?
      stop();
      upstep = 5;
      upspeed = 900;
      break;
     }
     
     //Check for incomming radio message at frequent intervals.
     if(stepcount < laststepcount - 500){
      laststepcount = stepcount;
      wait(1); //allows RX function.
     }
  }
    debouncerWINDOW.update();
}

void calibrate()
{
  //Move fully up or down and set stepcounter. - From controller, buttons or if position is unknown.....
}
/*
  long readVcc() {
  // Read 1.1V reference against AVcc
  // set the reference to Vcc and the measurement to the internal 1.1V reference
  ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
  wait(5); // Wait for Vref to settle
  ADCSRA |= _BV(ADSC); // Start conversion
  while (bit_is_set(ADCSRA,ADSC)); // measuring

  uint8_t low  = ADCL; // must read ADCL first - it then locks ADCH
  uint8_t high = ADCH; // unlocks both

  long result = (high<<8) | low;

  result = 1125300L / result; // Calculate Vcc (in mV); 1125300 = 1.1*1023*1000
  return result; // Vcc in millivolts
  }*/

It works like this......

Pressing up or down button will move the blind up or down depending on window sensor status (I don't want blinds to close with the window open)......

Whilst blind is in motion pressing button corresponding to the opposite direction will stop the blind and save position to eeprom.

Pressing both buttons at the same time for more than 5 seconds will call a self calibration routine.

At any point the controller should be able to send a message to the blinds to move or stop. This now happens even whilst the blind is in motion, which is what I thought to be the best option.

Every time the stop is called the position is saved to eeprom so that in the event of power interruption it will know where it last was.

Maybe I need to re-think the whole approach to this, but it is annoyingly close to what I would like now

[mfalkvidd]

@skywatch the reason you're getting the wait warning messages (and probably the reason why your code behaves in strage ways sometimes) is that you're calling send and wait from within receive. Doing so can have very strange side effects.

[mfalkvidd]

@skywatch also, requesting that the gateway echos sent messages back to your node will have very bad effects. Could you elaborate on what you are trying to achive by requesting echo?

[skywatch]

@mfalkvidd Ah, I didn't know that it also applied to a wait within other void loop - I'll change the code so that it just sets a variable and then modify the main loop accordingly. Thank you for your time - I know it was not easy to go through that lot! - Once it is working and tested I will tidy it up and optimise it all somewhat.

[skywatch]

@mfalkvidd said in void receive(const MyMessage &message):

@skywatch also, requesting that the gateway echos sent messages back to your node will have very bad effects. Could you elaborate on what you are trying to achive by requesting echo?

I simply wanted to know that the message got through. Otherwise the controller might send 'down' command without having received the window open status. - I will look into that too.....

[mfalkvidd]

@skywatch if you want to know that, you need to add code in receive() to handle the echoed message. And you need to make sure those echoed messages don't interfere with "normal" messages.

[skywatch]

@mfalkvidd Thank you soooo much for the tips with this, I still am learning new stuff and getting a project done = a double win for me

SO here is what I changed.....

In void loop I added

//Stop if received message = STOP
  if(RX_STOP == true){
    stop();
    }

And void receive() now looks like this ( I never needed to call up() or down() from here anyway. I realise that now - doh!).

void receive(const MyMessage &message) {

  // STOP - if message == V_STOP, stop blinds immediately.
  if (message.type == V_STOP) {
   RX_STOP = true;
  }

  // UP - if message == V_UP call void UP()
  if (message.type == V_UP) {
    MOVING_UP = true;
  }

  // DOWN - if message == V_DOWN call void DOWN()
  if (message.type == V_DOWN) {
    MOVING_DOWN = true;
  }

  //Add if (message.type==V_PERCENTAGE); and add calculation....maybe?
  // for reference 1% == 395 steps....
}

I'll test it later as I need some food now!

[mfalkvidd]

@skywatch great work. This is a much better design.

[skywatch]

@mfalkvidd Thank you!

And of course RX_STOP = false; is now at the end of the stop(); loop to reset it for next time it is needed.....I forgot that bit!

Update - it didn't work as expected, but I know why. I also had to change in the UP() and DOWN() loops from

 if (debouncerUP.fell()) {
    stop();
    }

To....

 if (debouncerUP.fell()|| RX_STOP == true) {
    stop();
    }

And then to completely mimic the button responses...

if (debouncerDOWN.fell() || RX_STOP == true || MOVING_DOWN == true) {
      stop();
    }

Now I am hungry and really will go get some food!

[skywatch]

@mfalkvidd said in void receive(const MyMessage &message):

@skywatch if you want to know that, you need to add code in receive() to handle the echoed message.

Is there a basic example of this anywhere? I can't see it...

And you need to make sure those echoed messages don't interfere with >"normal" messages.

It is mainly for the window sensor which as well as being useful for the blind, it will also form part of the security alarm system as well.

[mfalkvidd]

@skywatch no there is no example. We identified a need for such an example 3 years ago (see section 1 in https://forum.mysensors.org/post/34267 ) but so far no-one who understands how that stuff works has had sufficient time and motivation to do the necessary work. The task is very complicated.

[skywatch]

@mfalkvidd #sad (as Donald Trump would put it).....

Maybe think of removing.....
" Don’t worry, we’ll explain everything."
and....
"We provide easy to follow build instructions, ready to use code examples and adaptable open source hardware designs."
from the main page until the content matches the hype?

Seriously - 3 YEARS ???? - Just how hard can it be?

[mfalkvidd]

@skywatch if I ever get 2-3 days of continuous, undisturbed time I might be able to do it. But that will probably not happen anytime soon, and if it did happen there are probably other MySensors issues that would benefit more people I should focus on. Someone more skilled might be able to do it quicker.

[zboblamont]

@skywatch #sad, as Donald Trump would put it - "Seriously - 3 YEARS ???? - Just how hard can it be?" - Well it you can't build a Wall yourself...

[skywatch]

I just wish I could do it and post it, it is obviously needed.

@mfalkvidd - I wasn't suggesting it was your job to do this, but thanks for considering it. --- If I can help in any way let me know!
@zboblamont - I can't build a wall without mortar nor instructions on where and how high to build it (also bricks might come in handy come to think of it).

....and before I upset anyone, I know this is not a paid for product. There are many talented people working freely behind the scenes to make it happen.
But it's all pointless if it is not accessable to the people who want to be a part of it. _ I don't want a degree level thesis, just an example or two to work from.

[mfalkvidd]

@skywatch that's the hardest part. Making things so easy anyone can use it is 100x harder than just making it accessible to experienced people. I think MySensors has been able to make about 99% of what people want easily accessible. But the more stuff is easily accessible, people want to do more and more advanced stuff. So the more accessible things are, the less happy people are about it. This curse happens to all projects that are successful.

[skywatch]

@mfalkvidd This is drifted well off topic now - can I PM you?

[mfalkvidd]

@skywatch sure. But if the discussion is left in the open others can chip in, and others can read it and learn from it.

[skywatch]

@mfalkvidd Today it did some real testing with the actual setup (not a test node) and it is all working really well so far.

I was expecting to have to use limit switches to detect up and down limits, with microswitches to provide emergency power cut out to the motors if it overran. I even considered timing the motion too (done this with Crestron systems and curtains in the past).

But I have had two really great surprises......

1. The little stepper motors, when set within their comfort zone, are very precise. It looks like just counting steps is all that is required.
2. The steppers draw just 77mA when opening the blind. This is such good news for me as solar powered blinds (with li-ion or lead acid battery) will last all year!

Big thanks to you all for the hints and finding where I mis-understood. It won't be easy, but I will get there in the end.