Indeed it does. It depends on HOW you’re using the sensor. In my case, a single detected “vibration” does nothing. This is, in part, because I use it on a clothes dryer and simply shutting the dryer door will trigger a vibration. So, in my case, I monitor for repeated vibrations over a period of time to detect the dryer as running, and then I monitor for those vibrations to stop to detect the dryer as finished. In this particular use case, the Home Assistant MQTT sensor works just fine.
1 Like
Can you please provide your code showing how you’re able to monitor for repeated vibration over a period of time to detect the dryer as running? I keep falling on my face with this.
I don’t want to use the cache and happy to manually configure the sensors in Home Assistant but you get the issue (that the cache resolves) that values are wiped out when not included. Receiving your three message would result in only pressure having a value and the other two a “-”. I have worked around this with an if statement in the sensor but was wondering if you solved it differently.
My code uses a custom_component that I wrote that works as a timer, because the built in Home Assistant Timer is a little annoying for my tastes. But here’s the basic idea.
Create an input_select to keep track of the state of the dryer: “Running”, “Starting”, or “Stopped”.
Make an automation that triggers on Vibration with a condition of “Stopped”:
trigger:
- platform: state
entity_id: sensor.vibration_dryer
to: 'vibration'
condition:
- condition: state
entity_id: input_select.clothesdryer
state: 'Stopped'
The action on this automation should start a 5 minute timer (or however long it takes you to typically unload your dryer).
Make another automation that listens for the timer event the fires when the above timer expires. It should also have the “Stopped” condition from above. The action should set the input_select to “Starting”.
Make an automation that triggers on the “Starting” status for 5 minutes with an action that sets it back to “Stopped”.
Make another automation that triggers on vibration with a condition of the “Starting” status. The action should set the status to “Running” and start a 5 minute timer (less if your dryer is really wobbly, more if it isn’t).
Make another automation that triggers on the event fired when the above timer expires. It should have a condition of “Running” and the action will set the Status to “Stopped”.
Make another automation that triggers on vibration with a condition of the “Running” status. It’s action should simply restart the timer.
What happens is, if the dryer is “Stopped” and vibration is detected, you could be unloading clothes, or the dryer could be running, we don’t know yet. So we wait 5 minutes (to make sure you’ve finished unloading clothes) and then set the status to “Starting” which means the dryer MIGHT be starting. If 5 minutes goes by without any vibration, then the dryer isn’t running so we set the status back to “Stopped”. But, if during that second 5 minute window we see a vibration then the dryer must be running, so set the status to “Running”. Then we wait for a 5 minute period with no vibrations to know that the dryer is done.
It can be fooled, of course. If you take longer than 5 minutes to unload the dryer, it’ll think it’s running, and then some time later, it’ll go back to “Stopped” and you’ll probably have an alert automation for the stopped status, so you’ll get a false positive on that alert. Or, if you are, perhaps, loading the washer during that second 5 minute window and accidentally bump the dryer, same issue. So, occasionally, you can get false positives.
If you don’t care about false positives at all, then you could make every vibration while “Stopped” go straight to “Running”. However, when you unload your dryer, it’ll think you’ve started it again and 5 minutes after unloading you’ll get another “Stopped” alert.
It’s not an easy automation to write. And it takes quite a bit of tweaking. And Home Assistant’s very limited automation capabilities make it a lot less simple than it could be.
1 Like
Yes, I’ve worked this around with if as well. It make the config a bit more painful, especially knowing you have to restart home assistant every time you change the sensor config…
value_template: "{% if 'temperature' in value_json %} {{ value_json.temperature }} {% else %} {{ states('sensor.temperature_aqara_12') }} {% endif %}"
at the moment I’m still configuring this by hand, I’ll either use some kind of Makefile to generate the zigbee2mqtt part, but it might as well be easier to hack zigbee2mqtt so it auto configures home asssitant with my own config statements.
Or even better, I’d prefer if home assistant was not wiping the attributes not included in mqtt messages. (don’t know if this is a bug or a feature)
Hi,
I have been using a cc2531 for a few weeks now as I have been experimenting with HA using Hass.io.
Up until a few days ago I had a few Xiaomi sensors and was using them with NodeRed before diving into purchasing lights or sockets.
However since joining my first Ikea Tradfri light LED1624G9, the debugger no longer works.
With my most recent attempt at reinstalling zigbee2mqtt (well specifically zigbee2mqtt-edge) and starting from scratch (again!), I get the following log:-
Sun, 04 Nov 2018 13:07:07 GMT zigbee-shepherd zigbee-shepherd is _ready and _enabled
zigbee2mqtt:info 2018-11-4 13:07:07 zigbee-shepherd started
zigbee2mqtt:info 2018-11-4 13:07:07 Coordinator firmware version: 'undefined'
zigbee2mqtt:debug 2018-11-4 13:07:07 zigbee-shepherd info: {"enabled":true,"net": {"state":"Coordinator","channel":11,"panId":"0x1a63","extPanId":"0xdddddddddddddddd","ieeeAddr":"0x00124b0012013a09","nwkAddr":0},"firmware":{"error":"Unable to get firmware version"},"startTime":1541336827,"joinTimeLeft":0}
Also, normally I disable the led via the Hass.io configuration and this doesn’t seem to be working and sending any messages via MQTT fails:-
zigbee2mqtt:debug 2018-11-4 13:20:09 Received MQTT message on 'zigbee2mqtt/bridge/config/permit_join' with data 'true'
zigbee2mqtt:info 2018-11-4 13:20:09 Zigbee: allowing new devices to join.
Sun, 04 Nov 2018 13:20:09 GMT zigbee-shepherd:request REQ --> ZDO:mgmtPermitJoinReq
zigbee2mqtt:info 2018-11-4 13:20:12
{"message":"request timeout","stack":"Error: request timeout\n at CcZnp.<anonymous> (/app/node_modules/cc-znp/lib/ccznp.js:255:22)\n at Object.onceWrapper (events.js:315:30)\n at emitOne (events.js:116:13)\n at CcZnp.emit (events.js:211:7)\n at Timeout.<anonymous> (/app/node_modules/cc-znp/lib/ccznp.js:234:18)\n at ontimeout (timers.js:498:11)\n at tryOnTimeout (timers.js:323:5)\n at Timer.listOnTimeout (timers.js:290:5)"}
Basically nothing works as it once did and I can no longer add devices.
Do I need to re-flash my cc2531, as the process described to reset with the S2 button doesn’t seem to help?
How can I find out the firmware version or perform any further diagnostics?
Many thanks.
Has anyone been able to get this working with the CC2530? I’ve tried it directly wired and through a USB TTL converter, re-flashed and still nothing…
Are there additional steps required beyond just wiring it in correctly and setting up the addon?
Is there a changelog for the CC2531 firmware? I am interested to know what changes are being made as I dont want to have to rejoin my 25+ devices (after flashing) unless there are some features or fixes that I would find useful.
Compare versions of https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/CC2531/README.md
Fist of all, many thanks for releasing this @Koenkk. I just followed the detailed instructions and everything works first time with no issues on a raspberry pi3 running home assistant. I have tried to join a couple of xiaomi temperature sensors. They paired and report valid values. My only concern is that they both seem to report values twice or more, all the time. So my log looks like:
Nov 06 09:33:39 raspberrypi3 npm[12524]: zigbee2mqtt:info 2018-11-6 09:33:39 MQTT publish, topic: 'zigbee2mqtt/xiaomi_temperature_1', payload: '{"temperature":21.17,"linkquality":34,"humidity":62.6,"battery":"100.00","voltage":3175}'
Nov 06 09:33:39 raspberrypi3 npm[12524]: zigbee2mqtt:info 2018-11-6 09:33:39 MQTT publish, topic: 'zigbee2mqtt/xiaomi_temperature_1', payload: '{"temperature":21.13,"linkquality":34,"humidity":63.55,"battery":"100.00","voltage":3175}'
Nov 06 09:37:57 raspberrypi3 npm[12524]: zigbee2mqtt:info 2018-11-6 09:37:57 MQTT publish, topic: 'zigbee2mqtt/xiaomi_temperature_2', payload: '{"temperature":20.17,"linkquality":120,"humidity":65.63,"pressure":1006,"battery":"31.00","voltage":2965}'
Nov 06 09:37:57 raspberrypi3 npm[12524]: zigbee2mqtt:info 2018-11-6 09:37:57 MQTT publish, topic: 'zigbee2mqtt/xiaomi_temperature_2', payload: '{"temperature":20.17,"linkquality":118,"humidity":65.5,"pressure":1006,"battery":"31.00","voltage":2965}'
Nov 06 09:37:57 raspberrypi3 npm[12524]: zigbee2mqtt:info 2018-11-6 09:37:57 MQTT publish, topic: 'zigbee2mqtt/xiaomi_temperature_2', payload: '{"temperature":20.17,"linkquality":118,"humidity":65.5,"pressure":1006,"battery":"31.00","voltage":2965}'
Nov 06 09:51:22 raspberrypi3 npm[12524]: zigbee2mqtt:info 2018-11-6 09:51:22 MQTT publish, topic: 'zigbee2mqtt/xiaomi_temperature_2', payload: '{"temperature":20.17,"linkquality":128,"humidity":65.5,"pressure":1006,"battery":"31.00","voltage":2965}'
Nov 06 09:51:22 raspberrypi3 npm[12524]: zigbee2mqtt:info 2018-11-6 09:51:22 MQTT publish, topic: 'zigbee2mqtt/xiaomi_temperature_2', payload: '{"temperature":20.23,"linkquality":128,"humidity":65.75,"pressure":1006.71,"battery":"31.00","voltage":2965}'
Nov 06 10:12:31 raspberrypi3 npm[12524]: zigbee2mqtt:info 2018-11-6 10:12:31 MQTT publish, topic: 'zigbee2mqtt/xiaomi_temperature_2', payload: '{"temperature":20.36,"linkquality":126,"humidity":65.75,"pressure":1006.71,"battery":"31.00","voltage":2965}'
Nov 06 10:12:31 raspberrypi3 npm[12524]: zigbee2mqtt:info 2018-11-6 10:12:31 MQTT publish, topic: 'zigbee2mqtt/xiaomi_temperature_2', payload: '{"temperature":20.36,"linkquality":126,"humidity":65.48,"pressure":1006.71,"battery":"31.00","voltage":2965}'
Nov 06 10:12:31 raspberrypi3 npm[12524]: zigbee2mqtt:info 2018-11-6 10:12:31 MQTT publish, topic: 'zigbee2mqtt/xiaomi_temperature_2', payload: '{"temperature":20.36,"linkquality":126,"humidity":65.48,"pressure":1007,"battery":"31.00","voltage":2965}'
Looking at the file database.db, I see kind of duplicated entries (truncated file to show only beginning of lines)?
{"id":1,"type":"Coordinator","ieeeAddr":"0x00124b0018ed22cd", "nwkAddr":0,"manufId":0,"epList":[1,2,3,4,5,6],"status":"o ...
{"id":2,"type":"EndDevice","ieeeAddr":"0x00158d00015aeff7", "nwkAddr":18084,"manufId":4151,"manufName":"LUMI","powerSour ...
{"id":3,"type":"EndDevice","ieeeAddr":"0x00158d0001d6df5a", "nwkAddr":24414,"manufId":4151,"manufName":"LUMI","powerSour ...
{"$$indexCreated":{"fieldName":"id","unique":true,"sparse":false}}
{"id":1,"type":"Coordinator","ieeeAddr":"0x00124b0018ed22cd", "nwkAddr":0,"manufId":0,"epList":[1,2,3,4,5,6],"status":"o ...
{"id":2,"type":"EndDevice","ieeeAddr":"0x00158d00015aeff7", "nwkAddr":18084,"manufId":4151,"manufName":"LUMI","powerSour ...
{"id":3,"type":"EndDevice","ieeeAddr":"0x00158d0001d6df5a", "nwkAddr":24414,"manufId":4151,"manufName":"LUMI","powerSour ...`
Is this normal behaviour? Thanks!
I would answer NO. the database.db is a mess ! 
<= EDIT, it’s the normal behavior, see post relative the nedb
I would say if it’s working, don’t touch it
If you start having issues pairing new devices you might need to edit it to remove bad incomplete entries.
OK Thanks! In case I need to remove bad entries, should I keep the {"$$indexCreated":{"fieldName":"id","unique":true,"sparse":false}} line in the database.db file?
I would not touch the database, or at least have a backup. The db is meant to be only managed by zigbee-shepherd
I think you need to keep it, I don’t fully understand the file structure.
the database support comes from https://github.com/louischatriot/nedb
I guess it would be nicer to have some oneliners to repair/optimize/clean the database.db
indeed, do make a backup before altering it.
at the moment, altering the database by hand is the only way to solve so pairing issues.
talking about database.db I’ve just read https://github.com/louischatriot/nedb#persistence
I’m not sure objectbox is exposing compaction to zigbee-sheperd
but nedb is supposed to compact the database when loading it, if I run a simple js script just loading the database, it is compacted and saved compacted. looks like it doesn’t occur with zigbee2mqtt.
$ cp data/database.db /tmp/
$ wc -l /tmp/database.db
75 /tmp/database.db
$ cat > t.js << EOF
var ObjectBox = require('objectbox');
var box = new ObjectBox('/tmp/database.db');
EOF
$ node t.js
$ wc -l /tmp/database.db
36 /tmp/database.db
@lolorc said “I would answer NO”. But, what they meant was, YES this is normal behavior for zigbee2mqtt it’s just not the behavior they would desire.
Multiple entries for the same device in the database is normal.
yes, I’ve edited my post.
database should be compacted and then the duplicates and deleted entries should be removed from the file.
I guess we need some proper tools to alter/repair the database.db when wrong entries get stored. at the moment we do it by hand and it’s not convenient.
Hey all,
How do I reset the power consumption for a Xiaomi Zigbee Power outlet?
It seems to show real time power and total consumption but I can’t see how to reset the total consumption.
Thank you
Thanks, doesnt look like there is a “Changelog” but I dont see any recent changes.