Query the status of devices periodically

Odysee · November 7, 2023, 2:37pm

Hi there,

I have the following situation:

I installed a thermostat and a window sensor in one room. With Meshbots, the thermostat is switched off when the window sensor is opened and switched on again when the window contact is closed.

Now it happens every now and then that the thermostat stays on despite the window contact being open or remains off despite the window contact being closed. I haven’t figured out yet if it’s because the window contact didn’t transmit the status or if the thermostat didn’t execute the command.

Now I came up with the following idea as a workaround:
The status of both devices is checked every x minutes and if the combination does not fit (for example the thermostat runs despite the window contact being open), a corresponding command is sent to correct this.

Can I also solve this with a Meshbot?

curiousB · November 7, 2023, 3:05pm

Yes, you should be able to do this quite easily. Just set up a meshbot to run on an interval. Then create a sub group that looks at switch and thermostat state. If they are not the same trigger a change in the thermostat state.

Something like this might get you started. Just substitute the types of devices you have (switch and thermostat).

Odysee · November 7, 2023, 3:14pm

Thanks! I’ll install that straight away and see if the system runs more reliably.

Odysee · November 7, 2023, 5:23pm

Would this work the way I think it would?
It is checked every 10 minutes and if the thermostat heats despite the window being open, it is switched off.

Odysee · November 7, 2023, 5:58pm

Another Meshbot for the other error case:

I have now created both cases manually (window open and thermostat switched on or window closed and thermostat switched off) and waited for the interval time. It seems to work.

It would be cool if this could be combined into a single meshbot.

osman · November 7, 2023, 6:17pm

Look at @Odysee 's screenshot. You can use XOR instead. It will give TRUE only if only one of the outputs is true. So it will mean they are in incompatible states.

Odysee · November 7, 2023, 6:54pm

If I install an XOR link Sensor Closed / TRV Heat, then the status would be TRUE for these two undesirable states:

Sensor Open / TRV Heat
Sensor Closed / TRV Off

But then how can I execute two conditional actions in the same Meshbot?
If Sensor Open and TRV Heat then → TRV Off
If Sensor Closed and TRV Off then → TRV Heat

osman · November 7, 2023, 7:05pm

You can use exceptions on actions. so each action executes only if the exception is true

Odysee · November 7, 2023, 7:27pm

I’m trying to implement this right now. I have now configured the two actions as follows:

Unfortunately I cannot select a capability in the exception for the second action. The entries do appear. But when I select one of them it is immediately deleted. Am I doing something wrong or is this a bug?

Odysee · November 7, 2023, 7:36pm

Animation

curiousB · November 7, 2023, 7:54pm

A couple comments.

To avoid a race condition you might want to put say a 10-20 second delay to start the action sequence. Then change the state of the thermostat. Might not be needed due to interval triggering scheme but I sometimes do this to to keep things tidy.

As for two meshbots, that i why I recommend XOR function. It will fire only if the door and thermostat are different. When they are the same nothing happens. Then in the action just change state where new state equals inverse (or toggle) of old state. I had a several meshbots with two versions for the positive and negative case then I discovered XOR and it simplified things into one meshbot.

Looks like you well on you way to sorting this out.

osman · November 7, 2023, 7:54pm

It may be a bug. Let us take it asap. I filed the bug. Engineers are in GMT+2 so let us some time.

Odysee · November 9, 2023, 3:41pm

I just remembered that I had this exact problem with my pool project in 2022-06. I couldn’t create a second action/exception:

cw-kid · November 9, 2023, 3:47pm

@osman

I can confirm I have the same problem as shown in that video above. On the second Action and its Exception when you select the Capability the Value drop down menu does then NOT appear.

Odysee · November 13, 2023, 10:18am

Any news on that?

Lately I’ve had the problem more often that the Z-Wave chip seems to hang up and no device can be reached. Support has already reset the Z-Wave chip twice and has now recommended a Meshbot to restart daily as an interim solution. I suspect that this is due to the two new meshbots, which check at the same interval whether the two devices have an undesirable condition and then correct it. This probably caused me to create a kind of endless loop, which then paralyzed the Z-Wave network.

If I could put the two together, the problem would probably be solved.

What do the commands that are sent to devices actually look like? For example, if a device is already turned on and the “turn on” action is started. Is the command then sent unnecessarily even though the state has already been reached?

cw-kid · November 13, 2023, 1:40pm

I’d also like to know more about this.

I think on the Vera platform if the device is already on and another on command is sent, the system doesnt then operate the device again.

I think, not 100% sure about this, so don’t quote me on it.

In fact I may try this while looking at the Vera system log.

UPDATE:

Not sure, but trying this on my Vera Plus with a Scene, it looks like in the logs it sends the ON command anyway again regardless that the switch was already ON.

08	11/13/23 14:39:25.010	Scene::RunScene running 305 Test - Z-WAVE Command <0x6c332520>
08	11/13/23 14:39:25.012	JobHandler_LuaUPnP::HandleActionRequest device: 367 service: urn:upnp-org:serviceId:SwitchPower1 action: SetTarget <0x6c332520>
08	11/13/23 14:39:25.012	JobHandler_LuaUPnP::HandleActionRequest argument newTargetValue=1 <0x6c332520>
06	11/13/23 14:39:25.012	Device_Variable::m_szValue_set device: 367 service: urn:upnp-org:serviceId:SwitchPower1 variable: Target was: 1 now: 1 #hooks: 0 upnp: 0 skip: 0 v:0x1582e28/NONE duplicate:1 <0x6c332520>

06	11/13/23 14:39:25.271	Device_Variable::m_szValue_set device: 367 service: urn:upnp-org:serviceId:SwitchPower1 variable: Status was: 1 now: 1 #hooks: 1 upnp: 0 skip: 0 v:0x1582e90/NONE duplicate:1 <0x7676c520>
04	11/13/23 14:39:25.272	<Job ID="2" Name="ON node 87" Device="367" Created="2023-11-13 14:39:25" Started="2023-11-13 14:39:25" Completed="2023-11-13 14:39:25" Duration="0.259126000" Runtime="0.258029000" Status="Successful" LastNote="SUCCESS! Transmit was OK" Node="87" NodeType="ZWaveNonDimmableLight" NodeDescription="Flood Lights Power"/> <0x7676c520>

Will look at an Ezlo hub next and its log.

The Ezlo logs are not so easy to read or understand as there are multiple log files and related information is stored in several of those log files.

You can SSH into the Ezlo hub login as root and run this command to tail the logs together. tail -F ha-*

I did this and then ran my Meshbot rule that turned on a Z-Wave switch that was already turned on. To me it looks like the Z-Wave script is run to turn on the light by setting its Switch Item to value true.

This part I think:

2023-11-13 15:24:31.581065 DEBUG: handleSetItemValue: Setting item value
2023-11-13 15:24:31.582716 DEBUG: sendExecutePluginScript: Execute script: HUB:zwave/scripts/set_item_value, with params: {
    "item_id": "630611aa123e4312889cdfb2",
    "source": {
        "id": "65523754123e4315f4e0ce1c",
        "type": "scene"
    },
    "value": true
}

This is other related stuff I saw in the logs:

==> ha-uid.log <==
2023-11-13 15:24:31.554140 DEBUG: RECV(NMA) <<< wss://nma-server7-cloud.ezlo.com:443/ <<< {
    "id": "43c42a57-77d4-4846-a2da-4f2551f7d897",
    "jsonrpc": "2.0",
    "method": "hub.scenes.run",
    "params": {
        "sceneId": "65523754123e4315f4e0ce1c"
    },
    "sender": {
        "conn_id": "4f864eee-ad43-4f77-878f-1dc0b7edeb30",
        "type": "ui"
    }
}
2023-11-13 15:24:31.554781 INFO : Received new command: hub.scenes.run
2023-11-13 15:24:31.577417 DEBUG: SEND(NMA) >>> wss://nma-server7-cloud.ezlo.com:443/ >>> {
    "error": null,
    "id": "43c42a57-77d4-4846-a2da-4f2551f7d897",
    "method": "hub.scenes.run",
    "result": {},
    "sender": {
        "conn_id": "4f864eee-ad43-4f77-878f-1dc0b7edeb30",
        "type": "ui"
    }
}
2023-11-13 15:24:31.579150 DEBUG: SEND(NMA) >>> wss://nma-server7-cloud.ezlo.com:443/ >>> {
    "id": "ui_broadcast",
    "msg_id": "65523faf123e43153fc68683",
    "msg_subclass": "hub.scene.run.progress",
    "result": {
        "notifications": [],
        "scene_id": "65523754123e4315f4e0ce1c",
        "scene_name": "Test - Z-WAVE Command",
        "status": "started",
        "userNotification": false
    }
}

"id": "ui_broadcast",
    "msg_id": "65523faf123e43153fc68683",
    "msg_subclass": "hub.scene.run.progress",
    "result": {
        "notifications": [],
        "scene_id": "65523754123e4315f4e0ce1c",
        "scene_name": "Test - Z-WAVE Command",
        "status": "started",
        "userNotification": false
    }
}
2023-11-13 15:24:31.616479 DEBUG: SEND(NMA) >>> wss://nma-server7-cloud.ezlo.com:443/ >>> {
    "id": "ui_broadcast",
    "msg_id": "65523faf123e43153fc68684",
    "msg_subclass": "hub.scene.run.progress",
    "result": {
        "notifications": [],
        "scene_id": "65523754123e4315f4e0ce1c",
        "scene_name": "Test - Z-WAVE Command",
        "status": "finished",
        "userNotification": true
    }
}

 "id": "ui_broadcast",
    "msg_id": "65523faf123e43153fc68684",
    "msg_subclass": "hub.scene.run.progress",
    "result": {
        "notifications": [],
        "scene_id": "65523754123e4315f4e0ce1c",
        "scene_name": "Test - Z-WAVE Command",
        "status": "finished",
        "userNotification": true
    }
}
}

==> ha-scenes_manager.log <==
2023-11-13 15:24:31.556602 DEBUG: handleRequestFromBus, request :{"global":false,"sceneId":"65523754123e4315f4e0ce1c"}
2023-11-13 15:24:31.557752 INFO : runActions: start "then" action block of a scene with ID=65523754123e4315f4e0ce1c
2023-11-13 15:24:31.575618 DEBUG: CoreDRemoteInterface::setItemValue(){"_id":"630611aa123e4312889cdfb2","source":{"id":"65523754123e4315f4e0ce1c","type":"scene"},"value":true}
2023-11-13 15:24:31.576145 DEBUG: CoreDRemoteInterface::setItemValue() - single: "630611aa123e4312889cdfb2"
2023-11-13 15:24:31.578303 DEBUG: CoreDRemoteInterface::setItemValue(): {
    "_id": "630611aa123e4312889cdfb2",
    "source": {
        "id": "65523754123e4315f4e0ce1c",
        "type": "scene"
    },
    "value": true

==> ha-cored.log <==
2023-11-13 15:24:31.580818 DEBUG: handleSetItemValue: Setting item value: {
    "_id": "630611aa123e4312889cdfb2",
    "source": {
        "id": "65523754123e4315f4e0ce1c",
        "type": "scene"
    },
    "value": true
}
2023-11-13 15:24:31.581065 DEBUG: handleSetItemValue: Setting item value
2023-11-13 15:24:31.582716 DEBUG: sendExecutePluginScript: Execute script: HUB:zwave/scripts/set_item_value, with params: {
    "item_id": "630611aa123e4312889cdfb2",
    "source": {
        "id": "65523754123e4315f4e0ce1c",
        "type": "scene"
    },
    "value": true
}

osman · November 14, 2023, 12:56pm

Hi @Odysee , @cw-kid

Yes the zwave command is sent even if the device is in same state. I confirmed it from logs and zwave sniffs.

For the exceptions bug , it is done by our dev team and in QA process. So we expect to have it on live next week.

Odysee · November 14, 2023, 1:26pm

Does it make sense to send the command even if the status has already been reached (perhaps if the current status of the device was not correctly transmitted to the controller)? That would cause unnecessary traffic. Maybe you could make it configurable to determine whether it should still be sent in this case or not.

cw-kid · November 14, 2023, 5:09pm

I know I do this with Conditions in my MSR rules.

Check if a light is on first ? If not then turn it on etc.

We dont have “global” Conditions (exceptions) yet in Meshbots but they are coming soon hopefully.

Odysee · November 14, 2023, 6:48pm

That’s how it should work, right?