Need help reducing false positive notifications

[toggledbits]

Unfortunately there's nothing in the broadcast that ties it back to the original request, so that's going to eliminate the possibility of storing any broadcast response on the correct item/device. I've asked Oleh about this.

[Elcid]

Capturing the learnt rf/ir codes would be enough, it would remove the need to fire up the ezlo/vera App to capture codes. Maybe actions to learn_ir/rf_code and an ezlo broadcast listener in the tool section?

[toggledbits]

@elcid said in Ezlo device capabilities:

Capturing the learnt rf/ir codes would be enough,

Yup, that's the part I can't do correctly without connecting data.

[Elcid]

Ok we will see what Oleh has to say.
here is complete broadcast respnonse
1 send "learn_ir_code" _id with hub.item.value.set
2 after broadlink learns ir code.
3 when learn_ir_code resets to 0

3-
  {
    "date": 1626635249558,
    "data": {
      "id": "ui_broadcast",
      "msg_id": "60f47bf1122335125b847819",
      "msg_subclass": "hub.item.updated",
      "result": {
        "_id": "6059aab5122335123a08b974",
        "deviceCategory": "ir_tx",
        "deviceId": "6059aab5122335123a08b973",
        "deviceName": "RM pro lounge",
        "deviceSubcategory": "irt",
        "name": "learn_ir_code",
        "notifications": [],
        "roomName": "lounge",
        "serviceNotification": true,
        "syncNotification": false,
        "userNotification": false,
        "value": 0,
        "valueFormatted": "0",
        "valueType": "int"
      }
    }
  }

2-
  {
    "date": 1626635249517,
    "data": {
      "id": "ui_broadcast",
      "msg_id": "60f47bf1122335125b847818",
      "msg_subclass": "hub.extensions.plugin.ui_broadcast",
      "result": {
        "code": "JgBQAAABLJUVERQSFBEUEhQSFBEUNxQSFDcUNxM3FDcUNxQ3FBITNxQ3FBIUNxMSFBIUEhQRFBIUEhQ3ExIUNxQ3FDcUNxM3FAAFLQABLUkUAA0FAAAAAAAAAAA=",
        "plugin": "broadlink",
        "type": "IR"
      }
    }
  }

1-
  {
    "date": 1626635244363,
    "data": {
      "id": "ui_broadcast",
      "msg_id": "60f47bec122335125b847817",
      "msg_subclass": "hub.item.updated",
      "result": {
        "_id": "6059aab5122335123a08b974",
        "deviceCategory": "ir_tx",
        "deviceId": "6059aab5122335123a08b973",
        "deviceName": "RM pro lounge",
        "deviceSubcategory": "irt",
        "name": "learn_ir_code",
        "notifications": [],
        "roomName": "lounge",
        "serviceNotification": true,
        "syncNotification": false,
        "userNotification": false,
        "value": 1,
        "valueFormatted": "1",
        "valueType": "int"
      }
    }
  }

[toggledbits]

This is not the broadcast response we need, though. This is the one that resets the item back to 0 when the learn stops. A successful learn causes two broadcasts: this one to announce that the device has stopped learning, and a separate one to announce what was learned. It's that second broadcast that is missing the IDs we would need to tie it back to either the item or the device.

[Elcid]

Yes i understand that, I was just adding the full sequence for clarity.

[Elcid]

Just to report, the hub.item.value.set in msr 1.0 is working fine. I can send ir/rf codes, and initiate a rf/ir learn mode, i just have to listen for broadcasts to pick up the codes and copy and paste into msr.
P.s. congrats on the release of 1.0 and thank you.

[toggledbits]

You should also be able to use remote.send_codes. The format of the code data can either be a base64 string (in the format base64:datadatadata), or a list of byte values as decimal or hex values separated by spaces or commas (e.g. 0x00 0x12 0x2a 0xfe 0x14 for hex, 0 18 42 254 20 for decimal, and mixing is OK).

Should it support Pronto?

[Elcid]

@toggledbits remote.send_code has no input field.

As shown in above image

[toggledbits]

Whoops! I'll have that fixed in the next build. Remind me what package you are using (docker or bare metal, RPi, Linux, Windows?)

Edit: And the builds are up (latest).

[Elcid]

no luck with remote.send_codes with format base64:JgBYAAABJ5UQFBITERQRFBEUEBURExIUEDkRORE4ETkRORETEjkQORE4EjkQFBEUERQRFBEUEBURExITETkSOBE4ETkRORE4EQAFPwABJ0sRAAxHAAEnSxEADQU=
build reactor-latest-21200-17fb925.tar.gz

[toggledbits]

OK. Got your log file; thanks for that. Found the issue, will be fixed in today's "latest" build (21201).

[Elcid]

great, just one last question, I take it remote.send_codes will just send ir codes?

[toggledbits]

Yes, do you need RF as well?

[Elcid]

No, just confirming. I can use x_ezlo_device.set_item_value

[toggledbits]

I'm actually going to remove the remote capability and split it into ir_remote and rf_remote... I kind of realized I made an error making the capability name too generic. So that will be in today's build, which will break your actions, but I don't think we'll need to change it again.

[Elcid]

I took your early advice and have only been testing on MSR. Now 1.0 has been released, I will of course now start moving from Reactor to MSR. Having Ezlo Broadlink has brought my Broadlink under local (not sure if ezlo is using local or cloud integration for Broadlink, msr>>ezlo>>broadlink>>device, It seem instantaneous)) control, and I can now drop my Alexa remote2 workaround.

[toggledbits]

Cool. I just posted 21201. Since I can't test myself, you're the first to try. Let me know how it works out.

[Elcid]

21201 failed to load ezlo controller, I have uploaded a log file to mantis bug tracker

[toggledbits]

Can you look in your console logs (there is some logging that occurs prior to the internal logger being started, and it logs to the console), and see what it reports for the module path?