OpenHAB2 - Enable/Disable items until ESP Node acknowledges

[jimkernsjr]

Hi All...

Just a little background, since Computourist developed the great ESP nodes, I have put them to good use both on Sonoff's and an automated roller shade project I developed.  I actually have the shades working absolutely teriffic if I send it commands manually via MQTT.

About the programming:
I implemented a device 72, string type that takes the format Lnnn (LETTER, number number number) which is a command to control the shade.  Straight from my comments section:
//////////Accepted Device 72 commands:////////////////////////////
// //
// U020 up 20 in //
// D024 down 24 in //
// G010 goto 10 in down //
// P020 goto 20 percent down, so if 50" window same as a G10 //
// R000 resync - Home then back to same postion (more or less) //
// T000 led test - 3 blinks //
// //
// home/esp_gw/sb/node21/16 ON - turns on LED //
// home/esp_gw/sb/node21/16 OFF - turns off LED //
// //
// These commands should be sent to device 72, //
//i.e. home/esp_gw/sb/node32/dev72 G010 //
//////////////////////////////////////////////////////////////////


node 32 is a left shade, node 31 is a right shade in a pair of double windows together.

The hardware:
I built a L shaped hollow box, with an old HP printer stepper motor with a worm drive gear on the end, driven by a darlington to step it.  The roller shade has a gear glued to the side of it that sits on the worm gear and turns the shade.  The weight of the shade is plenty sitting on the gear for good tension.  It senses it's location by a hall sensor at the edge of the box, and a magnet glued inside the bottom bar of the shade.  Upon boot-up, and after it's first command, the first thing it does is wheel up the shade, find home, and either go back where it was (resync) or to where you moved it to.  It works a treat, accurate to about 2mm!

The problem:
While the ESP is busy driving the stepper, that is ALL it does.  It does not process client.loop() nor send acknowledgements.  When it receives a command, it acknowledges, then go.
For some reason, the code, especially then 2 are online simultaneously, tends to come disconnected.  Part of this is planned (during a motion) and partly not.  I really prefer NOT to interrupt the motion by sending it through client.loop while it's driving the stepper...for one, I do a ramp up to not skip teeth or misstep which will lead to an inaccuracy.  Seeing as though I don't always know how long client.loop would take, I prefer not to send it through while the shade is in motion.  The shade is in a 54" window, so it takes over a minute to go up/down to it's extremities. 

To work around said problem, I put a retry loop in the rules of the send mqtt command in OPENHAB.  It looks like this:

//Window Shades

//Dev 31 is right, dev32 is left



rule "Shade_HSE_MBR_Position_L Changed"

when

    Item Shade_HSE_MBR_Position_L received update

then

    Shade_HSE_MBR_Ack_L.state=OFF

    val pval = String::format("P%1$03d", (Shade_HSE_MBR_Position_L.state as DecimalType).intValue)

    // "mqtt publish" with retry loop

    logInfo("rules", "*Rules-Shade_HSE_MBR_Position_R update to: " + pval + ". Transmitting/Posting MQTT msg. RuleRev.6");

    var iL = 1

    while ((iL<50) && (Shade_HSE_MBR_Ack_L.state==OFF)){

        Pub_Shade_HSE_MBR_Command_L.sendCommand(pval)

        //logInfo("rules", "*Rules-Shade_HSE_MBR_Position_L -TX msg " + iL);

        Thread::sleep(1000)

        iL++

    }

    logInfo("rules", "*Rules-Shade_HSE_MBR_Position_L updated to: " + pval + " after " + iL + " tries.");

    if (Shade_HSE_MBR_LockTogether.state == ON && Shade_HSE_MBR_Position_R.state != Shade_HSE_MBR_Position_L.state)         {Shade_HSE_MBR_Position_R.state=Shade_HSE_MBR_Position_L.state}

end





I seem to find now that OpenHAB tends to resend messages, even after the shade starts to move.  I tend to think that from what I can tell from the log, very often when the slider is moved, it triggers more than once.  As you can see, I have a little ACK switch hidden in my items that it watches to know when it's successful.  So the problem I've now created is:
    Slider moved, and maybe "fumbled"
    1st MQTT msg send,
    shade acknowledges, slider moves on
    second MQTT msg sent
    shade is now busy and wont acknowledge, so it keeps sending.
    shade is done, finally gets the message again

I use Computourist's built in device 5 to acknowledge BTW

I can sent it for example G005 (Goto 5%), G054, G000, etc etc, and it will aways go where it's told, never misbehaving.  I do it with OpenHAB and all H@## breaks loose like it's possessed. 

Any better ideas how I can handle the OpenHAB side of it?  What I'd really like would be move the slider, disable it, send the message, receive acknowledgement, and when the motion is complete, send one final acknowledgement to re-enable.  During this process, disable the rule from a second trigger.  I really would prefer not to "rig" the ESP code around the problem, because I feel it's ideal the way it is.  I think my code in OpenHAB "spamming" the MQTT bus is really more the problem.

I really went to alot of trouble over this project, and I really want to share the whole thing when I'm done here, including wiring diagrams, rules, parts list, and a 3D print of the housing box.  I put too much into it now to just use it for 2 windows for myself, I hope someone else can get some good out of it.

Any ideas?

[computourist]

Hi jimkernsjr,

seems to me you are really stretching for the limits ;-)

I think your problem lies in the time-out of the connection between MQTT-broker and client. When your code is busy controlling the stepper motor it doesn't respond to any mqtt-messages. The broker will decide the client is no longer alive and will drop the connection. If this is what's causing your problems the root of the problem is on MQTT level, and not easy to fix in Openhab: as long as the client is not responding to MQTT messages, you can send anything from Openhab with no effect.

IMO you could try the following solutions:

- increase time-out value of Mosquitto. I'm not sure where, but it should be in the config somewhere.
- use interrupts to answer any requests on the MQTT link
- use a separate Arduino for motor control. It should be easy to forward your control string over the serial port to a second Arduino that executes the stepper motor control. The ESP can be decicated to the MQTT client code.
- use a central gateway design as used in the RFM setup. In this case the MQTT link is connected to a gateway, and no time-outs are used on the client <-> gateway link.

Success, and I would love to see some description of your final setup.

Rgds,
Computourist

[jimkernsjr]

Computourist, thanks!

As usual, you've been a great help!

I like all your ideas, but heres my situation with each:
- increase time-out value of Mosquitto. I'm not sure where, but it should be in the config somewhere.
*OK, but it's still a 54" window, and if it has to do a resync due to a power failure, it's still all the way up and back down. It could be 2 minutes or more, so maybe that's a idea, but I'll save that for last
- use interrupts to answer any requests on the MQTT link.
*OK, but again, this affects stepper motor operation. There's perfect timing to drive that and if I stop to handle an interrupt, then I have to time that operation, and do a ramp up on the speed again if operation too long. Not a bad idea, but not my first choice.
- use a separate Arduino for motor control. It should be easy to forward your control string over the serial port to a second Arduino that executes the stepper motor control. The ESP can be decicated to the MQTT client code.
*thought of that too. But my enclosure is VERY tight now and I have no more room! Further, I already built my circuit boards that the ESP goes on and I dont think I can get that big of a modification in...
- use a central gateway design as used in the RFM setup. In this case the MQTT link is connected to a gateway, and no time-outs are used on the client <-> gateway link.
*I was going to use that initially, but I dont have a gateway at this house where this is installed. Not that that's a huge problem, but I just loved your new code so much I really wanted to do it without. Also, same as above, I have alot of time in building the boards and they are already done, so I'd rather try to fix what I have...

So, all that being said, you gave me a great idea! Is there a way to "gracefully disconnect" from MQTT? I thought I read that somewhere. Any ideas how to do that in openhab, I.E. a switch that has "node offline"? I could terminate the rule based on that. If all else fails, I could implement another device into your sketch with a "busy" flag. I really think you are onto something with that!

Tell me what you think if there is something existing for the disconnect...I swore I read about that somewhere and now I just cant remember where. I think it had to do with a persistent message, then when it came back on it was deleted with a non-persistent message, but my memory could be failing me on this...

Again,thanks so much. I really think I have this thing in the home stretch. I need to get the OTA programming in it too, but I want to make sure it has no ill effects before I do that. I'm eager to document it all, but unfortunately, I'm not Papa when it comes to that so I hope I can do such a clear and concise job as he does. Behind it is a great deal of mechanical operations too, so it's not complete without drawings and such of that.

Best regards,
Jim

[papa]

jimkernsjr, thanks for the kudos on my documentation. Yes, documenting projects takes extra effort & it's maybe daunting going public. However, it's manageable if one takes it a step at a time, collecting instructions, diagrams, & pics, editing those & then copying & pasting into this forum.

I find several rewards in doing documentation: 1) Aiming to explain things clears my head & often gives me other ideas about how to do something or expand its utility. 2) In appreciation for others' contribution to this project (like Eric Tsai, computourist, gandalph, etc), I get the satisfaction of passing it on & sharing my efforts & insights on this forum. 3) Getting forum members positive feedback encourages me to keep going. 4) Forum members are always respectful & helpful in pointing out my mistakes or better ways to accomplish things. 5) The act of documenting fixes the concepts & process more firmly in my mind. 6) Aiming to explain things for others nudges me to go beyond just getting something to work, to go deeper in understanding & testing a project. 7) The next time I do a project, the documentation I post here is often what I use refresh my memory & guide me.

The above cause me to be as clear & detailed as I can in documentation.

I hope you will dive in & document your project.