Domoticz

Posted: **Friday 05 January 2024 20:51**

Hi,

I'm running Domoticz 2024.1 on Raspberry PI using Mosquitto MQTT broker and ZWave-JS-UI interface to Aeotec Gen5 stick. Latest stable versions of everything, and the system is working great!

My question has to do with Domoticz handling of multiple identical events. This comes up because I have a wall switch that I want to program for "extra" pushes in each On/Off direction. One push would turn on the light itself, a second push might turn on additional room lights, a third push... But, although I can see MQTT events being sent with each additional button push, Domoticz only seems to create a LUA event for the first one, i.e., the initial transition from the opposite state. However, I also have an Aeotec WallMote that sends repeated "holddown" events and Domoticz DOES pass all of those through.

I'm pretty sure that the problem is not in ZWave-JS-UI, because I can simulate these two different behaviors by manually publishing this simple MQTT event:

Code: Select all

{ "value": false }

repeatedly to the "state_topic" for each device, and the two still behave differently (all the WallMote events get through to LUA, but only the first On->Off switch event).

I'm using Domoticz MQTT Auto Discovery which received the following homeassistant config stanzas to create each device:

Code: Select all

{
  "state_topic": "zwave/WallMoteA/central_scene/endpoint_0/scene/001",
  "json_attributes_topic": "zwave/WallMoteA/central_scene/endpoint_0/scene/001",
  "value_template": "{{ value_json.value | default('') }}",
  "device": {
    "identifiers": [
      "zwavejs2mqtt_0xc5aaa324_node2"
    ],
    "manufacturer": "AEON Labs",
    "model": "WallMote Quad (ZW130)",
    "name": "WallMoteA",
    "sw_version": "1.8"
  },
  "name": "WallMoteA_scene_state_scene_001",
  "unique_id": "zwavejs2mqtt_0xc5aaa324_2-91-0-scene-001"
}

Code: Select all

{
  "payload_off": false,
  "payload_on": true,
  "value_template": "{{ value_json.value }}",
  "command_topic": "zwave/BED2-MoSw/switch_binary/endpoint_1/targetValue/set",
  "state_topic": "zwave/BED2-MoSw/switch_binary/endpoint_1/currentValue",
  "device": {
    "identifiers": [
      "zwavejs2mqtt_0xc5aaa324_node3"
    ],
    "manufacturer": "GE/Enbrighten",
    "model": "In-Wall Motion Switch, 500S (26931 / ZW4006)",
    "name": "BED2-MoSw",
    "sw_version": "5.39"
  },
  "name": "BED2-MoSw_switch_1",
  "unique_id": "zwavejs2mqtt_0xc5aaa324_3-37-1-currentValue"
}

The devices both seem to be working properly in every regard, it's just that repeated events are somehow handled differently. Can anyone suggest why this is happening and how that behavior could be modified. Thanks so much!

Posted: **Tuesday 16 January 2024 3:21**

Thank you to everyone who took the time to read my original post. I've made some progress the past ten days and have both a workaround and a possible code enhancement to offer.

The suppression of successive identical switch levels is done in this code from hardware/MQTTAutoDiscover.cpp

Code: Select all

3476  // check if we have a change, if not do not update it
3477  if (
3478          (switchType != STYPE_PushOn)
3479          && (switchType != STYPE_PushOff)
3480          )
3481  {
3482          if ((!bOn) && (nValue == 0))
3483          {
3484                  if (!bHaveLevelChange)
3485                  {
3486                          if (!bHaveColorChange)
3487                                  return;
3488                  }
3489          }
3490          if ((bOn && (nValue != 0)))
3491          {
3492                  // Check Level
3493                  int slevel = atoi(sValue.c_str());
3494                  if (slevel == level)
3495                  {
3496                          if (!bHaveColorChange)
3497                                  return;
3498                  }
3499          }
3500  }

This is checking for anything that might reasonably count as "change", and then only passing those events through. In almost all cases this is exactly how users want to see their switches, and everybody's happy.

If the above lines are commented out, then ordinary switches will report ALL of their button push activities, not just the ones that reflect a change of state. As described in the original post, this behavior allows you to do "interesting things" with a switch by pushing it a few more times in the direction it's already in. So, I'm wondering if being able to control this behavior via some sort of per-switch configuration parameter might be a useful code enhancement.

But for the moment, and needing to press on using standard unmodified code, a workaround is also possible. The switch MQTT config from the original post had been published (by ZWave-JS-UI) to the

homeassistant/switch/BED2-MoSw/switch_1/config

topic (sorry, I'd forgotten to mention that).

So, using the lovely MQTT Explorer tool, I simply created a "sensor" version of the switch by publishing:

homeassistant/sensor/BED2-MoSw/pushed/config

Code: Select all

{
  "value_template": "{{ value_json.value }}",
  "state_topic": "zwave/BED2-MoSw/switch_binary/endpoint_1/currentValue",
  "name": "BED2-MoSw-Pushed",
  "unique_id": "BED2-MoSw-Pushed"
}

i.e., define a sensor that monitors the same state_topic as the original switch. This creates a new Domoticz device that successfully sees all button events and sends all of those "re-pushes" to LUA code. I was very happy to see them appear, but a little help is still needed on the LUA side to filter the activity into genuine re-push events, something like:

Code: Select all

repush =
   ( devicechanged['BED2-MoSw-Pushed'] ~= nil ) and

   ( ( devicechanged['BED2-MoSw-Pushed'] == 'true' ) ==
     ( otherdevices ['BED2-MoSw-Switch'] == 'On'   ) ) and

   ( timeAgeInSeconds( otherdevices_lastupdate['BED2-MoSw-Switch'] ) > 1 )

This cleanly filters genuine re-push events by insisting that 1) someone just pressed the switch, 2) it was pressed in the same direction it's already in, and 3) there have not been any "real" switch reports/toggles for at least two seconds. This nicely cleans up both the manual button pushes, and also the flurry of activity brought on by Domoticz commands that change state. When both the Switch and the Pushed events are received at the same time, the order in which LUA sees them seems to be undefined. The above cleanup code does the right thing regardless of the order of arrival.

Domoticz

Domoticz handling of multiple identical events

Domoticz handling of multiple identical events

Re: Domoticz handling of multiple identical events