Node-RED and Associations

Hi, I’m Norwegian so you are welcome to answer in norsk! I’m trying to make a virtual Z-Wave device in Node-RED but I have some difficulity to know what I have to set in the inclusion report to make “associations” available in the app. Any idea?

The inclusion report is looking like this:

{
    "type": "evt.thing.inclusion_report",
    "serv": "door_lock",
    "val_t": "object",
    "val": {
        "integr_id": "",
        "address": "01JCEBK7GAFXYR8AZ075AP7JSQ",
        "type": "",
        "product_hash": "virtualdoor_01JCEBK7GAFXYR8AZ075AP7JSQ",
        "alias": "Virtual Door",
        "comm_tech": "cloud",
        "product_id": "",
        "product_name": "Virtual Door",
        "manufacturer_id": "lostfields",
        "device_id": "01JCEBK7GAFXYR8AZ075AP7JSQ",
        "hw_ver": "1",
        "sw_ver": "1",
        "power_source": "ac",
        "wakeup_interval": "-1",
        "security": "",
        "tags": null,
        "groups": [
            "1"
        ],
        "prop_set": null,
        "tech_specific_props": null,
        "services": [
            {
                "name": "door_lock",
                "alias": "door lock",
                "address": "/rt:dev/rn:zw/ad:1/sv:door_lock/ad:01JCEBK7GAFXYR8AZ075AP7JSQ",
                "enabled": true,
                "groups": [
                    "1"
                ],
                "props": {
                    "sup_modes": [
                        "secured",
                        "unsecured"
                    ],
                    "sup_components": [
                        "is_secured",
                        "door_is_closed"
                    ]
                },
                "tags": null,
                "prop_set_ref": "",
                "interfaces": [
                    {
                        "intf_t": "cmd.lock.set",
                        "msg_t": "in",
                        "val_t": "bool",
                        "ver": "1"
                    },
                    {
                        "intf_t": "cmd.lock.get_report",
                        "msg_t": "in",
                        "val_t": "null",
                        "ver": "1"
                    },
                    {
                        "intf_t": "evt.lock.report",
                        "msg_t": "out",
                        "val_t": "bool_map",
                        "ver": "1"
                    }
                ]
            }
        ]
    },
    "tags": null,
    "props": null,
    "ver": "1",
    "corid": "",
    "src": "node-red",
    "ctime": "2024-11-13T19:06:55.326Z",
    "uid": "bfacf719-2ac9-48a0-884f-35309d6c24fd"
}

What I was hoping to achieve was an easy way to configure my virtual device either through Z-Wave associations or parameters.

That may be a feature outside the MQTT protocol, but I don’t know, I’m a beginner in this world.

If that isn’t possible, I have to set the configurations somewhere else.

Hey!
Z-Wave association works in a way where device A sends payloads directly to associated device B (not via the smarthub). When the state of device B change it will send “updated info” back to the gateway (smarthub).
I do not think you are able to “fake” an association - especially since door locks also have encryption for the payloads.
What is the end goal on what you want to achieve? There might be other solutions to your problem

What I’m trying to solve is to make configuration changes for my Adapter without leaving Futurehome. I know we have Edge apps, so I could do it there instead, or putting the configuration in the cloud. Don’t think there is any other ways?

@Espen, is it possible to make an Edge app and run it on the Hub without publishing it through Futurehome? I haven’t found out how to do that.

Is it possible to tell Futurehome that the Adapter supports settings like you can do for Edge apps?

Well, I found it. I have to use the service “parameters” in the inclusion report and it worked amazingly good!

I tried the “parameter” service with the sup_parameter example and it looks like this in the app

There is an “association” service as well I’m going to try out!

Or, that was what I thought I did… I sent this service and got the above, that doesn’t seem right.

{
  "name": "parameters",
  "alias": "parameters",
  "address": "/rt:dev/rn:nodered/ad:1/sv:basic/ad:"+address,
  "enabled": true,
  "groups": [
    "1"
  ],
  "props": {
    "sup_parameter": [
      {
        "parameter_id": 1,
        "name": "Sensitivity of the PR sensor",
        "widget_type": "select",
        "value_type": "int",
        "options": [{"label":"Option 1", "value": 1}],
        "min": -1,
        "max": 20,
        "default_value": 1,
        "read_only": false
      }
    ]
  },
  "tags": null,
  "prop_set_ref": "",
  "interfaces": [
    {
      "intf_t": "cmd.sup_params.get_report",
      "msg_t": "in",
      "val_t": "null",
      "ver": "1"
    },
    {
      "intf_t": "evt.sup_params.report",
      "msg_t": "out",
      "val_t": "object",
      "ver": "1"
    },
    {
      "intf_t": "cmd.param.set",
      "msg_t": "in",
      "val_t": "object",
      "ver": "1"
    },
    {
      "intf_t": "cmd.param.get_report",
      "msg_t": "in",
      "val_t": "object",
      "ver": "1"
    },
    {
      "intf_t": "evt.param.report",
      "msg_t": "out",
      "val_t": "object",
      "ver": "1"
    }
  ]
}