Navigation

    Logo
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Unread
    • Categories
    • Unreplied
    • Popular
    • GitHub
    • Docu
    • Hilfe
    1. Home
    2. olixAtiobroker

    NEWS

    • Neuer Blog: Fotos und Eindrücke aus Solingen

    • ioBroker@Smart Living Forum Solingen, 14.06. - Agenda added

    • ioBroker goes Matter ... Matter Adapter in Stable

    O
    • Profile
    • Following 0
    • Followers 0
    • Topics 4
    • Posts 19
    • Best 1
    • Groups 1

    olixAtiobroker

    @olixAtiobroker

    Starter

    1
    Reputation
    10
    Profile views
    19
    Posts
    0
    Followers
    0
    Following
    Joined Last Online

    olixAtiobroker Follow
    Starter

    Best posts made by olixAtiobroker

    • Script für eigene Alarmanlage auf Zigbee Basis (IAS ACE)

      The Zigbee ZCL standard https://zigbeealliance.org/wp-content/uploads/2019/12/07-5123-06-zigbee-cluster-library-specification.pdf defines a so called "Intruder Alarm System" (IAS).
      The specification describer interaction between security devices and the intruder alarm system.
      Some examples include:

      • Linkind ZS130000078 Security keypad battery
      • Linkind ZS130000178 Security system key fob
      • Immax Neo 07046L 4 Buttons
      • Centralite security keypads

      Those Zigbee ZCL IAS security devices can been registered successfully at iobroker.zigbee adapter but they need several responses from a security system to work properly.
      Since these responses are not generated within the iobroker.zigbee adapter nor the zigbee.herdsman driver the devices keep sending repeated messages and report transmission failures (red leds etc) after some timeout.
      More complex devices like panels will probably not work at all.

      Nevertheless with the following changes the iobroker.zigbee adapter is enabled to forward those responses to the devices when triggered from a js script.

      @developer.js

      in async sendToZigbee(obj)
      add 
      else if (cmdType === 'functionalResp') {
        cmd = zcl.Utils.getCluster(cid).getCommandResponse(obj.message.cmd); 
      }
      ...
      await this.zbController.publish(publishTarget, cid, cmd.name, zclData, cfg, ep, cmdType, (err, msg) => {}, obj.message.zclSeqNum);
      

      @zigbeecontroller.js

      add async publish()
      async publish(deviceID, cid, cmd, zclData, cfg, ep, type, callback, zclSeqNum) {}
      
      add
      else if () {
        if (!zclSeqNum) {
          this.error(
            `Zigbee cannot publish commandResponse message to device because zclSeqNum is not known`
          );
          return;
        }
        cfg.disableDefaultResponse = false;
        const result = await endpoint.commandResponse(cid, cmd, zclData, cfg, zclSeqNum);
        if (callback) callback(undefined, result);
      }
      
      

      I have generated pull request to integrate those changes: https://github.com/ioBroker/ioBroker.zigbee/pull/1283
      It has already been acceted but it may still need some time till it is being published.

      Now a "fake security system" needs to be created. The following js can be used as a very simple and incomplete template:

      var armMode = 0; //disarmed
      
      // register all devices added to iasace_keyfob or iasace_panel enum.function
      // note: msg_from_zigbee must be tagged
      on({enumId: /^enum\.functions\.iasace_(keyfob|panel)$/, change: "ne"}, function(obj) 
      {
          var msg_rcvd; 
          var senderId = obj.id.replace(".msg_from_zigbee", "");
          console.log('ZID:' + senderId);
          
          msg_rcvd = (function () { try {return JSON.parse(getState(obj.id).val);} catch(e) {return {};}})();
          console.log((' ID:' + obj.id + ' Msg:' + msg_rcvd.type + " SeqNum:" + msg_rcvd.meta.zclTransactionSequenceNumber + " ZoneID:" + msg_rcvd.data.zoneID));
      
          switch(msg_rcvd.type)
          {
              case "commandGetPanelStatus":
                  console.log(('Respond to commandGetPanelStatus\n'));
                  sendTo("zigbee.0", "sendToZigbee", { "id": senderId, "ep": "1", "cid": "ssIasAce", "cmd": "getPanelStatusRsp", "cmdType": "functionalResp", "zclSeqNum": msg_rcvd.meta.zclTransactionSequenceNumber, "zclData": {"panelstatus": armMode,"secondsremain": "10","audiblenotif":"1","alarmstatus":"0"} });
                  break;
              case "commandArm":
              // for now don't check PIN and just respond success
                  console.log(('Respond to commandArm for Zone: ' + msg_rcvd.data.armmode + ' PIN:' + msg_rcvd.data.code));
                  armMode = msg_rcvd.data.armmode;
                  sendTo("zigbee.0", "sendToZigbee", { "id": senderId, "ep": "1", "cid": "ssIasAce", "cmd": "armRsp", "cmdType": "functionalResp", "zclSeqNum": msg_rcvd.meta.zclTransactionSequenceNumber, "zclData": {"armnotification": msg_rcvd.data.armmode} });
              break;
        }
      });
      
      

      It registers to changes on the "msg_from_zigbee" state which all zigbee devices have.
      To only register for so called IAS ACE panel and keyfob devices I have created "enum.function.iasace_keyfob" and "enum.function.iasace_panel" enums and assigned them directly to the "msg_from_zigbee" states of the respective devices.
      The reason to handle keyfobs and panels differently ist that the panel might be publicly accessible and sends a PIN code, keyfobs don't send a PIN. Nevertheless this is not handled by above easy template.

      The main messages send by devices are:

      "commandArm" {"armmode":3,"code":"","zoneid":23}
      f.e. {"type":"commandArm","data":{"armmode":3,"code":"","zoneid":23},"linkquality":151,"groupID":null,"cluster":"ssIasAce","meta":{"zclTransactionSequenceNumber":8,"manufacturerCode":null,"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":0,"disableDefaultResponse":false,"reservedBits":0}},"endpoint_id":1}
      

      which requires a "cmd": "armRsp"{"armnotification": msg_rcvd.data.armmode} response

      and

      "commandGetPanelStatus" 
      f.e. {"type":"commandGetPanelStatus","data":{},"linkquality":255,"groupID":null,"cluster":"ssIasAce","meta":{"zclTransactionSequenceNumber":4,"manufacturerCode":null,"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":0,"disableDefaultResponse":false,"reservedBits":0}},"endpoint_id":1}
      

      which requires a
      "cmd": "getPanelStatusRsp" {"panelstatus": armMode,"secondsremain": "10","audiblenotif":"1","alarmstatus":"0"} response

      Fields are:
      armmode:
      --> following for command and response
      0x00 Disarmed (all zones disarmed) and ready to arm
      0x01 Armed stay
      0x02 Armed night
      0x03 Armed away
      --> following only for response
      0x04 Exit delay
      0x05 Entry delay
      0x06 Not ready to arm
      0x07 In alarm
      0x08 Arming Stay
      0x09 Arming Night
      0x0a Arming Away

      secondsremain
      f.e. "10"

      audiblenotif:
      0x00 Mute (i.e., no audible notification)
      0x01 Default sound
      0x80-0xff Manufacturer specific

      --> Alarm Status
      0x00 No alarm
      0x01 Burglar
      0x02 Fire
      0x03 Emergency
      0x04 Police Panic
      0x05 Fire Panic
      0x06 Emergency Panic (i.e., medical issue)

      To send responses the
      sendTo("zigbee.0", "sendToZigbee", { "id": senderId, "ep": "1", "cid": "ssIasAce", "cmd": "[getPanelStatusRsp|armRsp]", "cmdType": "functionalResp", "zclSeqNum": msg_rcvd.meta.zclTransactionSequenceNumber, "zclData": {...} });
      can be used.
      Sender ID must be same as from cmd.
      "cmd" must be one of [getPanelStatusRsp|armRsp]
      "cmdType" must be new "functionalResp"
      new "zclSeqNum" parameter must be same as from cmd.

      I think around this template a "fake" intruder alarm script can be generated according to your needs in an iobroker JS without a big hazzle.
      Thank you to @asgothian and @kirovilya for the great iobroker.zigbee adapter and their support!
      Oliver

      olix74 created this issue in ioBroker/ioBroker.zigbee

      closed Feature: CMD Response Support added #1283

      posted in JavaScript
      O
      olixAtiobroker

    Latest posts made by olixAtiobroker

    • RE: Test Adapter wireless-mbus v0.10.x

      @lvogt, ach ja und unterstützt Deine Implementierung "Generation 3 Profil A/ Generation 4 Profil B"?
      Nochmal Danke,
      Oliver

      posted in Tester
      O
      olixAtiobroker
    • RE: Test Adapter wireless-mbus v0.10.x

      Hallo @lvogt,
      erstmal vielen Dank für die Antwort. Der Diehl Sharky 775 ist ein "Hydrometer" und meiner hat die Seriennummer 4181-2788 - von daher passt der erste Teil der ID "HYD-2788", die "8042f" die danach kommt, hat keine Entsprechung.

      Laut Datenblatt unterstützt der Zähler "Open Metering Standard ... Generation 3 Profil A oder Generation 4 Profil B" - wobei ich mich da noch nicht schlau gemacht habe.

      Kannst Du mir einen "Link" auf die Spezifikation schicken (oder ggf. sagen, welche Spec. Du erwartest) bzw. was das Log-Telegramm zeigt? MBUS oder nur OMS (oder was anderes)? Ich würde dann ggf. weiter in den Specs. suchen, mir fehlt aber der Einstiegspunkt und eine Idee was das Log wirklich zeigt.

      Besten Dank und Grüße,
      Oliver

      posted in Tester
      O
      olixAtiobroker
    • RE: Test Adapter wireless-mbus v0.10.x

      Hallo, erstmal vielen lieben Dank für diesen Adapter!
      Ich habe eine Diehl Sharky 775, den ich gerne mit dem CUL Stick auslesen würde. Prinzipiell scheinen der Stick und der Adapter die Daten auch zu empfangen, allerdings erhalte ich immer folgende Message:

      Parser failed to parse telegram from device HYD-2788042f
      

      Hat schon mal jemand den Sharky Wärmezähler erfolgreich eingebunden?
      Bevor ich mich in wireless M-Bus und OMS einarbeite, wollte ich mal fragen ob jemand was mit der Message-Struktur unten anfangen kann und mir sagen, ob es eine gewisse Erfolgsaussicht zur Unterstützung gibt?
      Ich kann gerne bei einer Umsetzung unterstützen.
      Danke und Grüße,
      Oliver
      Hier das komplette Log:

      2022-10-03 22:18:58.201 - info: wireless-mbus.0 (27585) starting. Version 0.8.5 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v14.18.1, js-controller: 4.0.19
      2022-10-03 22:18:58.312 - debug: wireless-mbus.0 (27585) Created device of type: CUL
      2022-10-03 22:18:58.321 - debug: wireless-mbus.0 (27585) CUL: TX: 560d0a
      2022-10-03 22:18:58.338 - debug: wireless-mbus.0 (27585) CUL: RX: 000a
      2022-10-03 22:18:58.389 - debug: wireless-mbus.0 (27585) connected set to false
      2022-10-03 22:19:01.338 - info: wireless-mbus.0 (27585) CUL: Error getting CUL version: Timeout waiting for response
      2022-10-03 22:19:01.339 - debug: wireless-mbus.0 (27585) CUL: TX: 5832310d0a6272630d0a
      2022-10-03 22:19:01.360 - debug: wireless-mbus.0 (27585) CUL: RX: 434d4f44450d0a
      2022-10-03 22:19:01.361 - info: wireless-mbus.0 (27585) CUL: Receiver set to C-MODE and data reporting with RSSI
      2022-10-03 22:19:01.422 - debug: wireless-mbus.0 (27585) connected set to true
      2022-10-03 22:19:13.355 - debug: wireless-mbus.0 (27585) CUL: RX: 6237333434323432333246303438383237383134314543333437413845303036353730324436353933313941414436383745353241464532373737
      2022-10-03 22:19:13.386 - debug: wireless-mbus.0 (27585) CUL: RX: 3143393138384433333831344242304630454532324143413536304335334445353132344639433233463843324338303238414646354442383345313637433441443939314331414234324132414332443939414430323337464138323937423941424339444238413944303041313244304142463339
      2022-10-03 22:19:13.417 - debug: wireless-mbus.0 (27585) CUL: RX: 323731313237343641384236413839443531433641323446393543314131333236453930323133454242433835453531374545423738464441394237383339333932374337344237313830354146454331363345364142383133390d0a
      2022-10-03 22:19:13.419 - debug: wireless-mbus.0 (27585) CUL: Message received: 734424232f0488278141ec347a8e0065702d659319aad687e52afe27771c9188d33814bb0f0ee22aca560c53de5124f9c23f8c2c8028aff5db83e167c4ad991c1ab42a2ac2d99ad0237fa8297b9abc9db8a9d00a12d0abf3927112746a8b6a89d51c6a24f95c1a1326e90213ebbc85e517eeb78fda9b78393927c74b71805afec163e6ab8139
      2022-10-03 22:19:13.422 - debug: wireless-mbus.0 (27585) 734424232f0488278141ec347a8e0065702d659319aad687e52afe27771c9188d33814bb0f0ee22aca560c53de5124f9c23f8c2c8028aff5db83e167c4ad991c1ab42a2ac2d99ad0237fa8297b9abc9db8a9d00a12d0abf3927112746a8b6a89d51c6a24f95c1a1326e90213ebbc85e517eeb78fda9b78393927c74b71805afec163e6ab81
      2022-10-03 22:19:13.426 - debug: wireless-mbus.0 (27585) Short header
      2022-10-03 22:19:13.427 - error: wireless-mbus.0 (27585) Warning unknown security mode: 16
      2022-10-03 22:19:13.428 - error: wireless-mbus.0 (27585) Encryption mode 10 not implemented
      2022-10-03 22:19:13.431 - debug: wireless-mbus.0 (27585) Parser failed to parse telegram from device HYD-2788042f
      2022-10-03 22:19:46.124 - debug: wireless-mbus.0 (27585) CUL: RX: 62373334343234323332463034383832373831343145433334374139303030363535
      2022-10-03 22:19:46.156 - debug: wireless-mbus.0 (27585) CUL: RX: 443244374530354346384243424633354435314345433431464242383144443235454139424646423433443432343333373034383842374536413243463741373342323641323334414139384337413242454142393739464331443638373843344544423136424538354538453530353343364330333941364434
      2022-10-03 22:19:46.187 - debug: wireless-mbus.0 (27585) CUL: RX: 364541423334333938384239304443314233344233393430464632463934363231423130364135354135304537453945414338363744313632364445333137353435414630433030383244394436393735334631353846423638383736393938373834423330344243303541383033410d0a
      2022-10-03 22:19:46.188 - debug: wireless-mbus.0 (27585) CUL: Message received: 734424232f0488278141ec347a9000655d2d7e05cf8bcbf35d51cec41fbb81dd25ea9bffb43d4243370488b7e6a2cf7a73b26a234aa98c7a2beab979fc1d6878c4edb16be85e8e5053c6c039a6d46eab343988b90dc1b34b3940ff2f94621b106a55a50e7e9eac867d1626de317545af0c0082d9d69753f158fb68876998784b304bc05a803a
      2022-10-03 22:19:46.189 - debug: wireless-mbus.0 (27585) 734424232f0488278141ec347a9000655d2d7e05cf8bcbf35d51cec41fbb81dd25ea9bffb43d4243370488b7e6a2cf7a73b26a234aa98c7a2beab979fc1d6878c4edb16be85e8e5053c6c039a6d46eab343988b90dc1b34b3940ff2f94621b106a55a50e7e9eac867d1626de317545af0c0082d9d69753f158fb68876998784b304bc05a80
      2022-10-03 22:19:46.190 - debug: wireless-mbus.0 (27585) Short header
      2022-10-03 22:19:46.190 - error: wireless-mbus.0 (27585) Warning unknown security mode: 29
      2022-10-03 22:19:46.190 - error: wireless-mbus.0 (27585) Encryption mode 1d not implemented
      2022-10-03 22:19:46.191 - debug: wireless-mbus.0 (27585) Parser failed to parse telegram from device HYD-2788042f
      2022-10-03 22:20:02.644 - debug: wireless-mbus.0 (27585) CUL: RX: 6237333434323432333246303438383237383134314543333437
      2022-10-03 22:20:02.661 - debug: wireless-mbus.0 (27585) CUL: RX: 41393130303635353432443746373733423131373945453630434337463534383332334141453939453837463144333130313536373133454145353245
      2022-10-03 22:20:02.692 - debug: wireless-mbus.0 (27585) CUL: RX: 424530323030353732344644433145354636393541353541334141334546334534424344343635333537383533383235343733454342393633414644414531304634463830374346303336443037373439323641424643444546333635424443413838353642353330343744324345334542434435353038
      2022-10-03 22:20:02.722 - debug: wireless-mbus.0 (27585) CUL: RX: 31324339333430463242444344353941353636423130313939324230354230383735334244413534433141343030423738394544303436383732383133410d0a
      2022-10-03 22:20:02.723 - debug: wireless-mbus.0 (27585) CUL: Message received: 734424232f0488278141ec347a910065542d7f773b1179ee60cc7f548323aae99e87f1d310156713eae52ebe02005724fdc1e5f695a55a3aa3ef3e4bcd465357853825473ecb963afdae10f4f807cf036d0774926abfcdef365bdca8856b53047d2ce3ebcd550812c9340f2bdcd59a566b101992b05b08753bda54c1a400b789ed046872813a
      2022-10-03 22:20:02.724 - debug: wireless-mbus.0 (27585) 734424232f0488278141ec347a910065542d7f773b1179ee60cc7f548323aae99e87f1d310156713eae52ebe02005724fdc1e5f695a55a3aa3ef3e4bcd465357853825473ecb963afdae10f4f807cf036d0774926abfcdef365bdca8856b53047d2ce3ebcd550812c9340f2bdcd59a566b101992b05b08753bda54c1a400b789ed04687281
      2022-10-03 22:20:02.725 - debug: wireless-mbus.0 (27585) Short header
      2022-10-03 22:20:02.725 - error: wireless-mbus.0 (27585) Warning unknown security mode: 20
      2022-10-03 22:20:02.725 - error: wireless-mbus.0 (27585) Encryption mode 14 not implemented
      2022-10-03 22:20:02.726 - debug: wireless-mbus.0 (27585) Parser failed to parse telegram from device HYD-2788042f
      
      posted in Tester
      O
      olixAtiobroker
    • RE: Script für eigene Alarmanlage auf Zigbee Basis (IAS ACE)

      Just a short comment. New version 1.6.8 of zigbee adapter now includes above changes and no need to patch the driver anymore. Thus you can directly go for creating your "intruder alarm system" JS or blockly scripts.
      Best regards,
      Oliver

      posted in JavaScript
      O
      olixAtiobroker
    • RE: Zigbee Response aus JS oder Blockly schicken?

      Hallo @asgothian,
      ich habe mein Script mal entsprechend umgebaut und bekomme auch ein "success" allerdings, empfängt das Device scheinbar nichts/ nicht das Richtige. Ich werde mir das nochmal mit dem Debugger ansehen, wo es im Stack schiefgeht - allerdings schaffe ich das nicht am WE. Wie sähe die Nachricht für die GetPanelStatus Response aus?
      Danke nochmal und Grüße,
      Oliver

      posted in Skripten / Logik
      O
      olixAtiobroker
    • Script für eigene Alarmanlage auf Zigbee Basis (IAS ACE)

      The Zigbee ZCL standard https://zigbeealliance.org/wp-content/uploads/2019/12/07-5123-06-zigbee-cluster-library-specification.pdf defines a so called "Intruder Alarm System" (IAS).
      The specification describer interaction between security devices and the intruder alarm system.
      Some examples include:

      • Linkind ZS130000078 Security keypad battery
      • Linkind ZS130000178 Security system key fob
      • Immax Neo 07046L 4 Buttons
      • Centralite security keypads

      Those Zigbee ZCL IAS security devices can been registered successfully at iobroker.zigbee adapter but they need several responses from a security system to work properly.
      Since these responses are not generated within the iobroker.zigbee adapter nor the zigbee.herdsman driver the devices keep sending repeated messages and report transmission failures (red leds etc) after some timeout.
      More complex devices like panels will probably not work at all.

      Nevertheless with the following changes the iobroker.zigbee adapter is enabled to forward those responses to the devices when triggered from a js script.

      @developer.js

      in async sendToZigbee(obj)
      add 
      else if (cmdType === 'functionalResp') {
        cmd = zcl.Utils.getCluster(cid).getCommandResponse(obj.message.cmd); 
      }
      ...
      await this.zbController.publish(publishTarget, cid, cmd.name, zclData, cfg, ep, cmdType, (err, msg) => {}, obj.message.zclSeqNum);
      

      @zigbeecontroller.js

      add async publish()
      async publish(deviceID, cid, cmd, zclData, cfg, ep, type, callback, zclSeqNum) {}
      
      add
      else if () {
        if (!zclSeqNum) {
          this.error(
            `Zigbee cannot publish commandResponse message to device because zclSeqNum is not known`
          );
          return;
        }
        cfg.disableDefaultResponse = false;
        const result = await endpoint.commandResponse(cid, cmd, zclData, cfg, zclSeqNum);
        if (callback) callback(undefined, result);
      }
      
      

      I have generated pull request to integrate those changes: https://github.com/ioBroker/ioBroker.zigbee/pull/1283
      It has already been acceted but it may still need some time till it is being published.

      Now a "fake security system" needs to be created. The following js can be used as a very simple and incomplete template:

      var armMode = 0; //disarmed
      
      // register all devices added to iasace_keyfob or iasace_panel enum.function
      // note: msg_from_zigbee must be tagged
      on({enumId: /^enum\.functions\.iasace_(keyfob|panel)$/, change: "ne"}, function(obj) 
      {
          var msg_rcvd; 
          var senderId = obj.id.replace(".msg_from_zigbee", "");
          console.log('ZID:' + senderId);
          
          msg_rcvd = (function () { try {return JSON.parse(getState(obj.id).val);} catch(e) {return {};}})();
          console.log((' ID:' + obj.id + ' Msg:' + msg_rcvd.type + " SeqNum:" + msg_rcvd.meta.zclTransactionSequenceNumber + " ZoneID:" + msg_rcvd.data.zoneID));
      
          switch(msg_rcvd.type)
          {
              case "commandGetPanelStatus":
                  console.log(('Respond to commandGetPanelStatus\n'));
                  sendTo("zigbee.0", "sendToZigbee", { "id": senderId, "ep": "1", "cid": "ssIasAce", "cmd": "getPanelStatusRsp", "cmdType": "functionalResp", "zclSeqNum": msg_rcvd.meta.zclTransactionSequenceNumber, "zclData": {"panelstatus": armMode,"secondsremain": "10","audiblenotif":"1","alarmstatus":"0"} });
                  break;
              case "commandArm":
              // for now don't check PIN and just respond success
                  console.log(('Respond to commandArm for Zone: ' + msg_rcvd.data.armmode + ' PIN:' + msg_rcvd.data.code));
                  armMode = msg_rcvd.data.armmode;
                  sendTo("zigbee.0", "sendToZigbee", { "id": senderId, "ep": "1", "cid": "ssIasAce", "cmd": "armRsp", "cmdType": "functionalResp", "zclSeqNum": msg_rcvd.meta.zclTransactionSequenceNumber, "zclData": {"armnotification": msg_rcvd.data.armmode} });
              break;
        }
      });
      
      

      It registers to changes on the "msg_from_zigbee" state which all zigbee devices have.
      To only register for so called IAS ACE panel and keyfob devices I have created "enum.function.iasace_keyfob" and "enum.function.iasace_panel" enums and assigned them directly to the "msg_from_zigbee" states of the respective devices.
      The reason to handle keyfobs and panels differently ist that the panel might be publicly accessible and sends a PIN code, keyfobs don't send a PIN. Nevertheless this is not handled by above easy template.

      The main messages send by devices are:

      "commandArm" {"armmode":3,"code":"","zoneid":23}
      f.e. {"type":"commandArm","data":{"armmode":3,"code":"","zoneid":23},"linkquality":151,"groupID":null,"cluster":"ssIasAce","meta":{"zclTransactionSequenceNumber":8,"manufacturerCode":null,"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":0,"disableDefaultResponse":false,"reservedBits":0}},"endpoint_id":1}
      

      which requires a "cmd": "armRsp"{"armnotification": msg_rcvd.data.armmode} response

      and

      "commandGetPanelStatus" 
      f.e. {"type":"commandGetPanelStatus","data":{},"linkquality":255,"groupID":null,"cluster":"ssIasAce","meta":{"zclTransactionSequenceNumber":4,"manufacturerCode":null,"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":0,"disableDefaultResponse":false,"reservedBits":0}},"endpoint_id":1}
      

      which requires a
      "cmd": "getPanelStatusRsp" {"panelstatus": armMode,"secondsremain": "10","audiblenotif":"1","alarmstatus":"0"} response

      Fields are:
      armmode:
      --> following for command and response
      0x00 Disarmed (all zones disarmed) and ready to arm
      0x01 Armed stay
      0x02 Armed night
      0x03 Armed away
      --> following only for response
      0x04 Exit delay
      0x05 Entry delay
      0x06 Not ready to arm
      0x07 In alarm
      0x08 Arming Stay
      0x09 Arming Night
      0x0a Arming Away

      secondsremain
      f.e. "10"

      audiblenotif:
      0x00 Mute (i.e., no audible notification)
      0x01 Default sound
      0x80-0xff Manufacturer specific

      --> Alarm Status
      0x00 No alarm
      0x01 Burglar
      0x02 Fire
      0x03 Emergency
      0x04 Police Panic
      0x05 Fire Panic
      0x06 Emergency Panic (i.e., medical issue)

      To send responses the
      sendTo("zigbee.0", "sendToZigbee", { "id": senderId, "ep": "1", "cid": "ssIasAce", "cmd": "[getPanelStatusRsp|armRsp]", "cmdType": "functionalResp", "zclSeqNum": msg_rcvd.meta.zclTransactionSequenceNumber, "zclData": {...} });
      can be used.
      Sender ID must be same as from cmd.
      "cmd" must be one of [getPanelStatusRsp|armRsp]
      "cmdType" must be new "functionalResp"
      new "zclSeqNum" parameter must be same as from cmd.

      I think around this template a "fake" intruder alarm script can be generated according to your needs in an iobroker JS without a big hazzle.
      Thank you to @asgothian and @kirovilya for the great iobroker.zigbee adapter and their support!
      Oliver

      olix74 created this issue in ioBroker/ioBroker.zigbee

      closed Feature: CMD Response Support added #1283

      posted in JavaScript
      O
      olixAtiobroker
    • RE: Zigbee Response aus JS oder Blockly schicken?

      Hallo @asgothian ,
      ich habe jetzt einen Pull Request angelegt: https://github.com/ioBroker/ioBroker.zigbee/pull/1283 . Schau mal, ob das passen könnte. Falls ein Device für Tests bei Dir notwendig ist, dann könnte ich das ggf. sponsorn.
      Grüße, Oliver

      olix74 created this issue in ioBroker/ioBroker.zigbee

      closed Feature: CMD Response Support added #1283

      posted in Skripten / Logik
      O
      olixAtiobroker
    • RE: Zigbee Response aus JS oder Blockly schicken?

      Hallo @asgothian ,
      sendToDevice() hat das selbe Problem, dass keine CommandResponse Nachrichten mit ZclSeqNumber geschickt werden können. Geht also meiner Meinung nach nicht.
      Die Änderungen wären nach aussen absolut rückwärtskompatibel, da es ja nur einen erweiterter cmdType und einen optionalen Parameter zclSeqNum geben würde.
      Merkt also keiner, der es nicht braucht.
      Wie gesagt, die Änderungen sind fertig und seeehr überschaubar. Ich werde mal einen Pull Request erstellen und dann kannst Du mal schauen.
      Danke, Oliver

      posted in Skripten / Logik
      O
      olixAtiobroker
    • RE: Zigbee Response aus JS oder Blockly schicken?

      Hallo @asgothian,
      erstmal nochmal danke, für Deine Unterstützung. Ich denke ich konnte mein Problem jetzt lösen. Dazu habe ich im iobroker.zigbee Adapter zwei kleine Änderungen an developer.js und zigbeecontroller.js vorgenommen. Der Adapter sollte jetzt auch das Versender von commandResponses aus Scripten unterstützen - da der zigbee-herdsman das bereits kann.
      Damit lassen sich dann auch IAS ACE Devices (also Security Keyfobs und Security Panel) durch "Simulation" einer Alarmanlage per Script unterstützen.
      Zum Beispiel:

      • Linkind ZS130000078 Security keypad battery
      • Linkind ZS130000178 Security system key fob
      • Immax Neo 07046L 4 Buttons
      • dürfte auch mit Centralite security keypads funktionieren

      Gibt aber bestimmt noch weitere Anwednungsfälle.
      Ich würde Dir dafür gerne einen Pull Request stellen, wenn Du das generell unterstützen würdest?
      Anbei auch das Script an dem Du die kleinen Erweiterungen an der sendToZigbee, die jetzt "cmdType": "functionalResp", und einen optionalen "zclSeqNum": Parameter unterstützt, sehen kannst.
      Danke für Dein Feedback zu einem Pull Request,
      Oliver

      var armMode = 0; //disarmed
      
      // register all devices added to iasace_keyfob or iasace_panel enum.function
      // note: msg_from_zigbee must be tagged
      on({enumId: /^enum\.functions\.iasace_(keyfob|panel)$/, change: "ne"}, function(obj) 
      {
          var msg_rcvd; 
          var senderId = obj.id.replace(".msg_from_zigbee", "");
          console.log('ZID:' + senderId);
          
          msg_rcvd = (function () { try {return JSON.parse(getState(obj.id).val);} catch(e) {return {};}})();
          console.log((' ID:' + obj.id + ' Msg:' + msg_rcvd.type + " SeqNum:" + msg_rcvd.meta.zclTransactionSequenceNumber + " ZoneID:" + msg_rcvd.data.zoneID));
      
          switch(msg_rcvd.type)
          {
              case "commandGetPanelStatus":
                  console.log(('Respond to commandGetPanelStatus\n'));
                  sendTo("zigbee.0", "sendToZigbee", { "id": senderId, "ep": "1", "cid": "ssIasAce", "cmd": "getPanelStatusRsp", "cmdType": "functionalResp", "zclSeqNum": msg_rcvd.meta.zclTransactionSequenceNumber, "zclData": {"panelstatus": armMode,"secondsremain": "10","audiblenotif":"1","alarmstatus":"0"} });
                  break;
              case "commandArm":
              // for now don't check PIN and just respond success
                  console.log(('Respond to commandArm for Zone: ' + msg_rcvd.data.armmode + ' PIN:' + msg_rcvd.data.code));
                  armMode = msg_rcvd.data.armmode;
                  sendTo("zigbee.0", "sendToZigbee", { "id": senderId, "ep": "1", "cid": "ssIasAce", "cmd": "armRsp", "cmdType": "functionalResp", "zclSeqNum": msg_rcvd.meta.zclTransactionSequenceNumber, "zclData": {"armnotification": msg_rcvd.data.armmode} });
              break;
        }
      });
      
      
      posted in Skripten / Logik
      O
      olixAtiobroker
    • RE: Probleme mit Regex basiertem Trigger (gelöst)

      @olixatiobroker
      Hat sich erledigt, geht mit "obj", nicht lar wo das Problem vorher lag.
      Danke,
      Oliver

      posted in JavaScript
      O
      olixAtiobroker
    Community
    Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen
    The ioBroker Community 2014-2023
    logo