search

Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
11.92k stars 1.66k forks source link

Hue dimmer switch #36

Closed Trakkasure closed 6 years ago

Trakkasure commented 6 years ago

I hit the setup button on the back of the switch, and successfully paired the switch. Pressing any button on the switch does nothing. Interestingly, no light shows in the upper left corner on the device (like it usually does) when a button is pressed.

Is there additional support required in the sniffer firmware required to support this device? It would be great to be able to drop the hue hub all together and use my own home grown solution.

Below is the addition to the devices.js file:

{
'RWL020': {
        model: '324131092621',
    vendor: 'Philips',
    description: 'Hue Dimmer Switch',
        supports: 'single, double, triple, quadruple, many and long click',
        homeassistant: [homeassistant.sensor_click]
    }
}
arteck commented 6 years ago

can you merge this state.. Battery state is not that important to me..

tb-killa commented 6 years ago

@Koenkk Tested your latest Code Segment:

 2018-07-08T12:51:59.711Z - info: Device incoming...
2018-07-08T12:51:59.713Z - info: MQTT publish, topic: 'zigbee2mqtt/bridge/log', payload: '{"type":"pairing","message":"device incoming"}'
2018-07-08T12:51:59.716Z - info: New device with address 0x0017880103caab06 connected!
2018-07-08T12:51:59.748Z - info: MQTT publish, topic: 'zigbee2mqtt/bridge/log', payload: '{"type":"device_connected","message":"0x0017880103caab06"}'
2018-07-08T12:51:59.771Z - debug: Recieved zigbee message with data "online"
2018-07-08T12:52:02.236Z - info: Succesfully configured 0x0017880103caab06
2018-07-08T13:08:36.246Z - debug: Recieved zigbee message with data {"cid":"genPowerCfg","data":{"batteryPercentageRemaining":200}}
2018-07-08T13:08:36.251Z - warn: No converter available for '324131092621' with cid 'genPowerCfg' and type 'attReport'
2018-07-08T13:08:36.253Z - warn: Please see: https://github.com/Koenkk/zigbee2mqtt/wiki/How-to-support-new-devices.
tb-killa commented 6 years ago

@Koenkk Doesnt we could use the foundation function and parse the complete output of genPowerCfg ?

tb-killa commented 6 years ago

I implemented ignore attribute converter and the batterypercentageremaining (rudimental).

supports: 'on/off, brightness [0-255]',
        fromZigbee: [fz.ignore_324131092621,fz._324131092621_on, fz._324131092621_off, fz._324131092621_step, fz._324131092621_stop, fz._324131092621_power],

This needs to be revised again!

_324131092621_power: {
        cid: 'genPowerCfg',
        type: 'attReport',
        convert: (model, msg, publish, options) => {
            return {power: precisionRound(msg.data.data['batteryPercentageRemaining'], 2)};
        },
},
ignore_324131092621: {
        cid: 'genPowerCfg',
        type: 'devChange',
        convert: (model, msg, publish, options) => null,
},
Koenkk commented 6 years ago

Merged into dev branch: https://github.com/Koenkk/zigbee2mqtt/tree/dev

tb-killa commented 6 years ago

@Koenkk Why doesnt we could report the batteryVoltage(Attribute ID 0x0020) ?? I see at so many different samples that this work ??? Need this for https://github.com/Koenkk/zigbee2mqtt/issues/129 too :) Edit: On eCozy Thermostate i got it:

2018-7-10 19:15:32 DEBUG Recieved zigbee message with data {"cid":"genPowerCfg","data":{"batteryVoltage":29}}
Koenkk commented 6 years ago

@tb-killa It depens on how well the devices follows the Zigbee cluster specification. According to this battery voltage is not reportable, see: http://www.zigbee.org/~zigbeeor/wp-content/uploads/2014/10/07-5123-06-zigbee-cluster-library-specification.pdf @ 3.3.2.2.3

tb-killa commented 6 years ago

What do you think about implementing rudmental timer (like a function) who you could allow or deny the 30/120/xxx Minute call of read function? With this we could ping also Devices and check another states, because sometimes its easier to get battery Voltage since percentageremaining :)

jasonmhite commented 6 years ago

So I just got a chance to test the code you pushed to dev. It works well, the dimmer pairs and reports the right events for all the buttons.

The only thing that is missing is detecting long-press and double/triple click. I thought at least the long press is reported by the dimmer itself (it flashes an LED on the device to signal a long press), but I don't get any report from zigbee2mqtt at all (even with DEBUG=*). It shows the initial button press, but no followup event for holding the button down (debug log shows no output at all, not even an unhandled event).

I'm pretty sure the dimmer reports events for button down, button up and button hold, because that's what the bridge API reports.

Thanks for this though, just getting it working is awesome.

tb-killa commented 6 years ago

I´v got sometimes some Sort of Reporting of device already in network Messages and the Remote is not usable, it seems that the Device leave the Network and got in pairing to, and so one like a loop. I think this is caused of our actually binding logic.

I changes the Code to this and i doesn´t get any drops more:

configure: (ieeeAddr, shepherd, coordinator, callback) => {
            const ep1 = shepherd.find(ieeeAddr, 1);
            const ep2 = shepherd.find(ieeeAddr, 2);
            const actions = [
                (cb) => ep1.bind('genOnOff', coordinator, cb),
                (cb) => setTimeout(() => cb(false), 200),
                (cb) => ep1.bind('genLevelCtrl', coordinator, cb),
                (cb) => setTimeout(() => cb(false), 200),
                (cb) => ep2.bind('genPowerCfg', coordinator, cb),
                (cb) => setTimeout(() => cb(false), 200),
                (cb) => ep2.report('genPowerCfg', 'batteryPercentageRemaining', 1, 3600, 0, cb), // 3600 seconds = 1h - BatteryPercentageRemaining Reporting
                (cb) => setTimeout(() => cb(false), 100),
            ];

            execute(ep1, actions, callback);
        },
Koenkk commented 6 years ago

@tb-killa is this fixed by: https://github.com/Koenkk/zigbee-shepherd-converters/commit/64f3339347ec6dab8f8c9a06384668aecddd8c6d ?

tb-killa commented 6 years ago

@Koenkk We need rework of the BatteryPercentage Output: This is how it should be reported:

3.3.2.2.3.2 Bat teryPercentageRemaining At t ribute
Specifies the remaining battery life as a half integer percentage of the full battery capacity (e.g., 34.5%, 45%,
68.5%, 90%) with a range between zero and 100%, with 0x00 = 0%, 0x64 = 50%, and 0xC8 = 100%. This is
particularly suited for devices with rechargeable batteries.
The value 0xff indicates an invalid or unknown reading.
This attribute SHALL be configurable for attribute reporting.

RAW Output:

{ cid: 'genPowerCfg',
  data: { batteryPercentageRemaining: 200 } }
tb-killa commented 6 years ago

@Koenkk Your Comment: Koenkk/zigbee-shepherd-converters@64f3339 works great :) PS: with the old variant https://github.com/Koenkk/zigbee-shepherd-converters/blob/64f3339347ec6dab8f8c9a06384668aecddd8c6d/devices.js#L508 i got the drops. With the above variant everything work without drop and often showing red led by button push. Please include this and let the other User Test @arteck @jasonmhite

Koenkk commented 6 years ago

@tb-killa so that means { batteryPercentageRemaining: 200 } = 100%?

tb-killa commented 6 years ago

@Koenkk If we change 200 dec to hex it returns: C8 so if i check via official document it means 100%.

tb-killa commented 6 years ago

@Koenkk This seems to work and its valid:

return {Battery: Math.round(msg.data.data['batteryPercentageRemaining']/2)};
tb-killa commented 6 years ago

Damn: I got the Messages Drops again. The remote got red led and dely in pressing buttons. I think it forget their config and go in repairing mode again.

2018-7-15 11:26:35 DEBUG Recieved zigbee message with data "online"
device already in network
  zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: [object Object] +4s
  zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +8ms
  zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: [object Object] +2ms
2018-7-15 11:26:39 DEBUG Recieved zigbee message with data {"cid":"genLevelCtrl","data":{"stepmode":1,"stepsize":30,"transtime":9}}
2018-7-15 11:26:39 INFO MQTT publish, topic: 'zigbee2mqtt/0x0017880103caab06', payload: '{"Battery":52,"action":"down-press","brightness":205}'
  zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: [object Object] +1s
  zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +8ms
  zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: [object Object] +2ms
2018-7-15 11:26:40 DEBUG Recieved zigbee message with data {"cid":"genLevelCtrl","data":{"stepmode":0,"stepsize":30,"transtime":9}}
2018-7-15 11:26:40 INFO MQTT publish, topic: 'zigbee2mqtt/0x0017880103caab06', payload: '{"Battery":52,"action":"up-press","brightness":255}'
  zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: [object Object] +644ms
  zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +22ms
  zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: [object Object] +2ms
2018-7-15 11:26:41 DEBUG Recieved zigbee message with data {"cid":"genLevelCtrl","data":{"stepmode":1,"stepsize":30,"transtime":9}}
2018-7-15 11:26:41 INFO MQTT publish, topic: 'zigbee2mqtt/0x0017880103caab06', payload: '{"Battery":52,"action":"down-press","brightness":205}'
  zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: [object Object] +392ms
  zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +8ms
  zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: [object Object] +3ms
2018-7-15 11:26:41 DEBUG Recieved zigbee message with data {"cid":"genLevelCtrl","data":{"stepmode":0,"stepsize":30,"transtime":9}}
2018-7-15 11:26:41 INFO MQTT publish, topic: 'zigbee2mqtt/0x0017880103caab06', payload: '{"Battery":52,"action":"up-press","brightness":255}'
  zigbee-shepherd:msgHdlr IND <-- ZDO:tcDeviceInd +715ms
  zigbee-shepherd:msgHdlr IND <-- ZDO:tcDeviceInd +34ms
  zigbee-shepherd:msgHdlr IND <-- ZDO:tcDeviceInd +6s
spinlock: false []
device already in network
  zigbee-shepherd:msgHdlr IND <-- ZDO:endDeviceAnnceInd +22ms
  zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: [object Object] +11ms
  zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +8ms
  zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: [object Object] +10ms
2018-7-15 11:26:48 DEBUG Recieved zigbee message with data {"cid":"genOnOff","data":{"effectid":0,"effectvariant":0}}
2018-7-15 11:26:48 INFO MQTT publish, topic: 'zigbee2mqtt/0x0017880103caab06', payload: '{"Battery":52,"action":"off"}'
  zigbee-shepherd:msgHdlr IND <-- ZDO:tcDeviceInd +3s
spinlock: false []
device already in network
  zigbee-shepherd:msgHdlr IND <-- ZDO:endDeviceAnnceInd +53ms
  zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: [object Object] +9ms
  zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +5ms
  zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: [object Object] +1ms
2018-7-15 11:26:51 DEBUG Recieved zigbee message with data {"cid":"genOnOff","data":{}}
2018-7-15 11:26:51 INFO MQTT publish, topic: 'zigbee2mqtt/0x0017880103caab06', payload: '{"Battery":52,"action":"on"}'
  zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: [object Object] +2s
  zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +5ms
  zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: [object Object] +2ms
2018-7-15 11:26:53 DEBUG Recieved zigbee message with data {"cid":"genOnOff","data":{}}
2018-7-15 11:26:53 INFO MQTT publish, topic: 'zigbee2mqtt/0x0017880103caab06', payload: '{"Battery":52,"action":"on"}'
  zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: [object Object] +644ms
  zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +7ms
  zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: [object Object] +2ms
2018-7-15 11:26:54 DEBUG Recieved zigbee message with data {"cid":"genOnOff","data":{"effectid":0,"effectvariant":0}}
2018-7-15 11:26:54 INFO MQTT publish, topic: 'zigbee2mqtt/0x0017880103caab06', payload: '{"Battery":52,"action":"off"}'
  zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: [object Object] +5s
  zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +5ms
  zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: [object Object] +1ms
2018-7-15 11:26:59 DEBUG Recieved zigbee message with data {"cid":"genOnOff","data":{}}
2018-7-15 11:26:59 INFO MQTT publish, topic: 'zigbee2mqtt/0x0017880103caab06', payload: '{"Battery":52,"action":"on"}'
  zigbee-shepherd:msgHdlr IND <-- ZDO:tcDeviceInd +808ms
spinlock: false []
device already in network
  zigbee-shepherd:msgHdlr IND <-- ZDO:endDeviceAnnceInd +29ms
  zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: [object Object] +25ms
  zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +5ms
  zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: [object Object] +1ms
2018-7-15 11:27:00 DEBUG Recieved zigbee message with data {"cid":"genOnOff","data":{}}
2018-7-15 11:27:00 INFO MQTT publish, topic: 'zigbee2mqtt/0x0017880103caab06', payload: '{"Battery":52,"action":"on"}'
  zigbee-shepherd:af dispatchIncomingMsg(): type: incomingMsg, msg: [object Object] +2s
  zigbee-shepherd:msgHdlr IND <-- AF:incomingMsg, transId: 0 +4ms
  zigbee-shepherd:af dispatchIncomingMsg(): type: zclIncomingMsg, msg: [object Object] +2ms
2018-7-15 11:27:02 DEBUG Recieved zigbee message with data {"cid":"genOnOff","data":{}}
2018-7-15 11:27:02 INFO MQTT publish, topic: 'zigbee2mqtt/0x0017880103caab06', payload: '{"Battery":52,"action":"on"}'
Koenkk commented 6 years ago

@tb-killa could it be a battery problem?

tb-killa commented 6 years ago

@Koenkk Maybe, has to check this. But if i follow this conversation it seems to be a generic problem: https://community.smartthings.com/t/hue-dimmer-switch-connected-to-st/25840/158 Maybe because original it seems to be a ZHA Device .?

Koenkk commented 6 years ago

As some seem to have it and some not, could it be the model? Because we have: 'RWL020', 'RWL021'

tb-killa commented 6 years ago

Yes it thought about this too. Strange report from zigbee2mqtt: Every "Drop" and "Hangup" from the Device with "Red-LED" this messages come up:

 zigbee-shepherd:msgHdlr IND <-- ZDO:tcDeviceInd +992ms
spinlock: false []
device already in network

Could we check why this happened ?

jasonmhite commented 6 years ago

@Koenkk the remote I tested with is an RWL021 and I didn't notice this issue when I was testing it out yesterday. I have another but I think it's also a '21. I only played with it for 10 minutes or so though, does this error show up immediately or do I need to test for longer?

tb-killa commented 6 years ago

You need some more time. I could trigger this by pushing multiple Times fast the on or off Button.

arteck commented 6 years ago

i have here 2x RWL021 .. no problems .. since 3 days..

tb-killa commented 6 years ago

@Koenkk: Does we should do some more Tests or could we close this and bring in the Device Support as official ;) ? PS: After i Change my location of my Coordinator i doesn´t got any drops, seems to be the fault. Hint: We should change as last action the Time of BatteryReport to 3600 seconds max = 1h to conserve the battery!

Koenkk commented 6 years ago

@tb-killa it's already supported in the dev branch: https://github.com/Koenkk/zigbee2mqtt/tree/dev

Can this issue be closed?

tb-killa commented 6 years ago

If nobody will bring in changes we should close it and merge to Master.

nunoronconcouto commented 6 years ago 
{ groupid: 0,
  clusterid: 6,
  srcaddr: 125,
  srcendpoint: 1,
  dstendpoint: 1,
  wasbroadcast: 0,
  linkquality: 68,
  securityuse: 0,
  timestamp: 11020967,
  transseqnumber: 0,
  len: 3,
  data: { '0': 1, '1': 84, '2': 1 },
  zclMsg: 
   { frameCntl: { frameType: 1, manufSpec: 0, direction: 0, disDefaultRsp: 0 },
     manufCode: 0,
     seqNum: 84,
     cmdId: 'on',
     payload: {} } }
cmd { groupid: 0,
  clusterid: 6,
  srcaddr: 125,
  srcendpoint: 1,
  dstendpoint: 1,
  wasbroadcast: 0,
  linkquality: 68,
  securityuse: 0,
  timestamp: 11020967,
  transseqnumber: 0,
  len: 3,
  data: { '0': 1, '1': 84, '2': 1 },
  zclMsg: 
   { frameCntl: { frameType: 1, manufSpec: 0, direction: 0, disDefaultRsp: 0 },
     manufCode: 0,
     seqNum: 84,
     cmdId: 'on',
     payload: {} } }
  zigbee2mqtt:info 2018-9-10 01:39:12 MQTT publish, topic: 'zigbee2mqtt/0x0017880103a510d5', payload: '{"battery":100,"linkquality":68,"action":"on"}'
nunoronconcouto commented 6 years ago 
zigbee2mqtt:info 2018-9-10 19:11:05 MQTT publish, topic: 'zigbee2mqtt/0x0017880103a510d5', payload: '{"battery":100,"linkquality":92,"action":"up-press","brightness":105}'
zigbee2mqtt:info 2018-9-10 19:11:06 MQTT publish, topic: 'zigbee2mqtt/0x0017880103a510d5', payload: '{"battery":100,"linkquality":94,"action":"up-press","brightness":155}'
zigbee2mqtt:info 2018-9-10 19:12:39 MQTT publish, topic: 'zigbee2mqtt/0x0017880103a510d5', payload: '{"battery":100,"linkquality":94,"action":"down-press","brightness":105}'
zigbee2mqtt:info 2018-9-10 19:12:39 MQTT publish, topic: 'zigbee2mqtt/0x0017880103a510d5', payload: '{"battery":100,"linkquality":94,"action":"down-press","brightness":155}'
Curtis777 commented 6 years ago

is there any noob "How to get it work" to try them out before i return the remote ?

directman66 commented 5 years ago

The remote control 324131092621 does not respond to button presses. After pairing came only the answer about the connection and battery status.

2019-6-14 20:15:27 - info: Starting zigbee2mqtt version 1.4.0 (commit #927c4db) 2019-6-14 20:15:29 - info: Coordinator firmware version: '20190315'

only once message zigbee2mqtt/0x0017880104f2abb5 | {"battery":99.5,"linkquality":55}

hawaltie commented 5 years ago

In my case the the hue dimmer switch remote control does respond to button press. In mqtt it reports the following: zigbee2mqtt/0x0017880102d5ef3c', payload '{"battery":100,"linkquality":39,"counter":1,"brightness":105,"action":"on-press","duration":0 This trigger does not change the state of the remote for some reason, and therefore the related action is not triggered. Anyone a clue why the state is not changed?