Lights on with motion

I just don’t know where I’m going with this. I have a rule to turn some lights on in the kitchen:

//Motion Kitchen Evening
rule MotionDetectedKitchenEvening
when
        Item iKitchenMotion changed to ON
then
        if ( EveningMode == ON ) {
                logInfo("Kitchen", "Kitchen motion")
                iCabinetLEDsDimmer.sendCommand(50)
                iHoodLeftDimmer.sendCommand(50)
                iHoodRightDimmer.sendCommand(50)
                IKitchenCornerLampDimmer.sendCommand(50)
                iSonosLampDimmer.sendCommand(50)
                iLeftWallLightDimmer.sendCommand(50)
                iWallLightRightDimmer.sendCommand(50)
                Timer10minKitchen.sendCommand(ON)
        }
end

Evening mode is definitely on:

{
  "link": "http://192.168.1.66:8080/rest/items/EveningMode",
  "state": "ON",
  "editable": false,
  "type": "Switch",
  "name": "EveningMode",
  "label": "Evening Mode",
  "tags": [
    "Lighting"
  ],
  "groupNames": []
}

So why oh why do I get nothing in the log? I get the KitchenMotion changed from off to on. But no “loginfo” and the lights don’t react. These are concurrent entries in the log:

2020-05-15 20:31:23.281 [vent.ItemStateChangedEvent] - iKitchenMotion changed from ON to OFF

2020-05-15 20:31:32.710 [vent.ItemStateChangedEvent] - iKitchenMotion changed from OFF to ON

Starting to consider going back to SmartThings at the moment. The latency is awful (32 seconds at one count to switch one light on), discovering devices is excruciatingly painful, even things that were working yesterday have decided that they just aren’t going to work today. I’d be really interested to know if anyone has this working completely stably and what their configuration is. Am I just expecting too much from a Pi 4, an Xbee stick and an Aeotec Zwave stick. I’ve ordered a Conbee II to arrive on Sunday so I’ll give that a try with a couple of devices and see if that makes a difference.

Couple more days of playing and I think I’ll knock it on the head. There is no advantage with this (for me) in running locally over SmartThings and my patience is pretty good but getting low. The rest of the household are just walking into darkened rooms, tutting loudly and using the dumb switches on the walls.

but as you can see in the JSON, it has many properties; label, name, editable etc.

so this complex object will not equal ON.
It’s that state that you are interested in
if ( EveningMode.state == ON ) {

1 Like

Doh! I was messing with that rule earlier.

But this is one of many issues. I’ve lost count of the number of times I’ve sat here with sensors deleting them from Things, putting the sensor into discovery mode, running discover on OpenHAB again, the sensor is found, but never gets any further. Then by some random coincidence, it completes discovery and works. Even identical sensors - I bought 3 of the same. 2 took me a couple of hours to get discovered. one is just sat on the table and nothing I do will make it work. But it takes me about a minute to get it running on SmartThings. Conversely, the Zwave sensor in the bathroom gets detected twice, says it’s online and does nothing. The little green light on the sensor flashes when I walk in but nothing in the logs and the temp and luminance which were stuck now just say NULL.

And the latency. If I walk into the bathroom in the middle of the night, 30 seconds for the light to come on? I’m done and out by then.

What am I missing? I’ve bought a Pi, PSU, SD card, CC2531, Xbee stick, Zwave sensor, Conbee II on order - getting on for £150 to £200 just on the HW. Spent hours and hours on this. Moved the Pi to 3 different places. Like I say, I’d like to know how many people have had this installed and stable for any length of time. Show me someone, tell me what HW they’re running. I’ll spend some more money if there is a solution. But if the answer is just that this is bleeding edge and you have to put up with it then I’ll cut my losses now and go back to the SmartThings.

It’s not bleeding edge. Fix one problem at a time. Is this rule now fixed? Call it a success and move on to the next issue. If that’s too much trouble, go back to SmartThings and tolerate whatever it was that drove you away before. It’s entirely up to you, no-one is going to make these decisions for you.

I’ve got an openHAB instance running on version 1.8 still, runs on old Windows desktop with an extensive Modbus infrastructure. It gets rebooted every 6 months or so,because Windows. That’s no help at all to you.

That’s the problem. Nothing really drove me away from SmartThings. I just had my head turned by the prospect of running things locally. Am I wrong in thinking that should be close to zero latency?

Yes, thank you, that rule seems to be fixed.

So what controllers are you using for wireless devices? Zigbee? Zwave? I looked up Modbus. I understand serial communications but don’t get how that fits with wireless comms to smart home devices. Bear in mind, my knowledge of serial communications is based on being an IT engineer in the 80s so I’ve soldered more than a few 1, 2, 3 and 7 but that’s as far as it goes.

Latency should be acceptable, but can be ruined by many factors. When you’re ready. start a new thread sharing details of your problem.

That old openHAB runs nothing wireless, except a few WiFi devices. Said it’s no use to you.

No, it should be close to zero latency, but it’s not actually clear what you are having the latency problems with,. You mention a bunch of different devices which use lots of different technologies. Which one has the latency? Zwave? Zigbee?

A HUSZB-1 dual Zwave/Zigbee controller but prior to that I had Zwave running on a second generation Aeotech which I’ve deployed on an OH instance 100 miles away using some Dome motion sensors. I’ve never had latency problems. Years ago I would occasionally have inclusion problems with battery powered Zwave devices (Minimote and ZCombo smoke/CO alarms in particular) but haven’t had any problems since. I’ve been a pretty happy Zwave user on OH for half a decade or so. I’m running OH 2.5.4.

There really are thousands of users like me. But like rossko57 says, that doesn’t really help you except to know that it can be made to work.

it’s the Zigbee ones. I have loads of bulbs and a couple of RGBWW controllers. Just one example - this one’s actually an outlet which is about 3m and direct line of sight to the Pi with the Zigbee stick.

2020-05-15 22:12:15.217 [ome.event.ItemCommandEvent] - Item 'iLoungeLamp' received command OFF

2020-05-15 22:12:15.221 [nt.ItemStatePredictedEvent] - iLoungeLamp predicted to become OFF

2020-05-15 22:12:15.236 [vent.ItemStateChangedEvent] - iLoungeLamp changed from ON to OFF

But from hitting the button to the light actually going off was 9 seconds. If I did it 10 times, it would be the same in the logs. All three things happening immediately. Then the time taken for the device to respond could vary from so quickly I can’t detect a gap up to over 30 seconds. This one is a Samsung SmartThings outlet but most of my bulbs are IKEA Tradfri paired directly through the Zigbee binding rather than the IKEA hub thing. But there is no consistency that leads me to a pattern.

That’s what’s frustrating. I hear people saying these things. If they have this lovely, fast, stable setup using x, y and z then I should be able to replicate that and enjoy the same benefits.

The best I can offer is what’s discussed in the docs when things don’t appear to be working. Put the binding into debug, look at the logs for anything obvious. If you don’t see anything obvious, post the logs and ask for help. Someone, often the binding developer himself, is usually able to help.

Yep, done that, and posted the logs. I know this is run for free so I am not entitled to anything but I seem to get so far, get asked for logs, get asked for more logs, then nothing.

The log snippet you have shown does not include any obvious log for “button being hit”. What button? Is this some device, is there some rule as intermediary? Or is this a UI you are poking?
You’ll understand there is whole chain of actions here, some outside of openHAB, and you need to take an overview of the whole chain to see the problem area.

I’m trying both HABPanel and Paper UI. The inconsistency is the same on both. But it’s the same with a Zigbee sensor. I just walked into the kitchen. Less than one second for the lights to come on. That’s about 5m away and through 2 block walls. Just did the same for the utility room. 11 seconds. Probably a little bit closer and one block wall away. The lounge which is on a Zwave sensor:

LoungeSensor_MotionAlarm changed from OFF to ON

Nothing.

NightMode:

{
  "link": "http://192.168.1.66:8080/rest/items/NightMode",
  "state": "ON",
  "editable": false,
  "type": "Switch",
  "name": "NightMode",
  "label": "Night Mode",
  "category": "Lighting",
  "tags": [
    "Lighting"
  ],
  "groupNames": []
}

Lounge Lamp:

    {
      "link": "http://192.168.1.66:8080/rest/items/iLoungeLamp",
      "state": "OFF",
      "editable": true,
      "type": "Switch",
      "name": "iLoungeLamp",
      "label": "Lounge Lamp",
      "category": "Lighting",
      "tags": [],
      "groupNames": [
        "gLounge"
      ]
    }

Rule:

//Motion Lounge Night
rule MotionDetectedLoungeNight
when
        Item LoungeMotion changed to ON
then
        if ( NightMode.state == ON ) {
                logInfo("Lounge", "Motion lounge")
                iLoungeLamp.sendCommand(ON)
                Timer60minLounge.sendCommand(ON)
        }
end

This is where I hope you look at it and say “You forgot ‘x’ you muppet!”

Slow down. Fix one thing at a time, remember.
I’m not being arsey here, I’m offering the benefit of experience in how to fix multiple issues on a complex system I don’t fully understand.

Okay, the chain of events is quite obviously different for a motion triggered event and a UI commanded one.
Pick the simpler one - the UI command - and track that down.
If/when it’s mended, then see what’s left.

Right, point us to the already posted debug logs showing a delayed UI originated command.

1 Like

And a few minutes later with a new motion detect…

{
  "link": "http://192.168.1.66:8080/rest/items/iLoungeLamp",
  "state": "ON",
  "editable": true,
  "type": "Switch",
  "name": "iLoungeLamp",
  "label": "Lounge Lamp",
  "category": "Lighting",
  "tags": [],
  "groupNames": [
    "gLounge"
  ]
}

Working. I do wonder about this Xbee stick. Hopefully the Conbee will arrive on Sunday. I’ll add a couple of devices to that and see what sort of difference it makes.

If this is about the rule you started with here, I’ll note that it involves eight different commands, I assume at least some to real devices.
a) It takes a finite time to transmit, technology dependent.
b) Some bindings are better than others at handle a logjam.
But set that aside for now - I repeat my advice to concentrate on the simplest case, a single UI originating on/off, and show us detail.

No, this is the rule I posted just above. But looks like this:

//Motion Lounge Night
rule MotionDetectedLoungeNight
when
        Item LoungeMotion changed to ON
then
        if ( NightMode.state == ON ) {
                logInfo("Lounge", "Motion lounge")
                iLoungeLamp.sendCommand(ON)
                Timer60minLounge.sendCommand(ON)
        }
end

The one with 8 commands that you spotted my screwup with at the start is the one that worked instantly when I just went to the kitchen.

I think I’m going to hold fire now until the new stick arrives. There’s something funny about this Xbee, I’m sure of it.

Thank you so much for your help on this. I really don’t want to give up.

I’m surprised that works. Correct form -

rule "MotionDetectedLoungeNight"

The “name” of the rule does serve a function, and in passing, every rule must have a unique name.

Yes, I’ve seen some that have them. Usually if they put spaces in. Mine are half and half so I’ll put them all in quotes if that’s the way it should be.

If using one word as rule name it’s fine without quotes, so there should be no difference between
rule "MotionDetectedLoungeNight" and rule MotionDetectedLoungeNight, but it’s good style to keep the name in quotes :wink:
Be sure that every rule has a unique name, even when the rules are in different files.

But that rule is something, you should really care about after caring about the latency.

  • First step: connect one light to openHAB
  • Second step: connect that light to a Switch Item
  • Third step: Switch the Light through Paper UI control. Does that work without latency (i.e. not more than some 10 Milliseconds)?
  • Fourth step: Place the Switch Item onto a sitemap. Does that Switch work without latency?
  • Fifth step: connect a hardware Switch to openHAB (maybe a motion detector)
  • Sixth step: connect that Switch to another Item.
  • Seventh Step: take a look at the events.log when switching the switch. Does that work without latency? (see third step)
  • Eighth step: connect both Switches through a rule.
  • Ninth step: take another look at the events.log. you should see an event immediately when switching through the hardware switch, then after some 10 Milliseconds the Light should be turned on (through the rule).