In your automation that toggle the switch, before toggle it you need to call a service to set to true input_boolean.switch_by_automation
Then after the command to toggle the switch another call to service to set the boolean to false
Create an automation to check if the toggle is from human or automations:
Fire this automation when your switch change the state that check if the input_boolean.switch_by_automation is true or false to do your stuff!
If this doesn’t work you can introduce a little delay before setting input_boolean to false in the first automation to ensure the check from second automation work propertly
@tube0013@Koenkk I also have the same issue.
I’m knew to this. I setup the moskito addon and zigbee, flashed everything and once paired with the zigbee hassio integration, I only get one initial update. If I press the sensor, I get update for battery and connectivity quality, but not for the water leak. Did you manage to fix it?
Is there some tricks to do?
Not sure if this is something with new 1.3.0 version, or my configuration. I made fresh install of hass.io and configured mosquito and zigbee2mqtt. Earlier setup worked quite ok, but now badges doesn’t show values after hassio reboot until zigbee2mqtt is restarted, then everything works fine. Any suggestions whats wrong?
I’m getting an error which causes the bridge to be down:
zigbee2mqtt:error 4/11/2019, 3:45:57 AM Error while starting zigbee-shepherd!
zigbee2mqtt:error 4/11/2019, 3:45:57 AM Press the reset button on the stick (the one closest to the USB) and start again
zigbee2mqtt:error 4/11/2019, 3:45:57 AM Failed to start
{"message":"Error: No such file or directory, cannot open /dev/ttyUSB","stack":"Error: Error: No such file or directory, cannot open /dev/ttyUSB"}
zigbee2mqtt:error 4/11/2019, 3:45:57 AM Exiting...
Is there a way to fix this remotely? I am traveling and have no access to the physical device and would like to see if I can resolve remotely. Unfortunately restarting Hass.io was not helping…
Thanks @milakov and @nickrout! Adding the 0 in the add-on configuration resolved it. It stays a mystery how it had been working for months and I’ve not touched the configuration… Did I have the 0 and it just lost it or did it work without the 0 and all of a sudden it was required (unlikely…)
I believe the purpose of “grey ring up” is these devices tend to see a bit above themselves (i.e, they are meant to be placed on a coffee table, night stand, dresser, etc). By flipping them upside down (grey ring up) they can be mounted in a higher position and have visibility below themselves.
I am planning to use zigbee2mqtt for connection between my Raspberry Pi (Installed Raspbian OS and Hass.io) and Xiaomi sensors with distance around 100 metres between them.
My proposed systems as per below:
Connect Raspberry Pi with a CC2530 or CC2531 coordinator.
Set up 1-2pcs of CC2530 or CC2531 router to extend ZigBee signals between these two devices.
Xiaomi sensors
I have few questions before purchasing required components for setting up whole system above:
Is CC2530 or CC2531 better for coordinator and router? I need one with external antenna installed due to long range.
Could CC2531 coordinator communicate with CC2530 router or vice versa?
Some end devices like Xiaomi sensors parent router traffic goes offline, it don’t attempt to find a new parent so will remain isolated until re-paired with the network. As Xiaomi sensors might become inactive after some inactivity or Raspberry Pi is restarted due to unknown reason.
So, is there any solution for this issue beside pairing again manually?
When WIFI router which connected with Raspberry Pi is down (WIFI network is down completely and no public internet access), will Raspberry Pi still able to accept Xiaomi sensors status via MQTT in this case?
I’m sure I’ve just read that the main difference between the cc2531 vs. cc2530 , the cc2531 has internal usb on board. The 2530 does not. other then that there are interchangeable.
However I’m still a bit new to the zigbee of things way doing stuff, and could be wrong. Still reading and tinkering.
According to the documentation only the CC2531 can be used as an coordinator the CC2530 has a better range as a router.
Yes
This is true, Xiaomi devices don’t try to find a new/better router. But as soon as the router or coordinator to which your end device (Xiaomi Sensor) was initially connected comes online again, the end device will automatically reconnect to it.
Sensor messages between the Xiaomi Sensor and your CC2531 which is connected to your RPI still get sent via Zigbee. If you attach a monitor to your RPI you can still see the messages in the log. MQTT messages however don’t get sent when the RPI has no network (WIFI down)
As long as Xiaomi sensors connect back to initially connected coordinator when it is online, then this should be fine.
Means that I cannot tigger HA light/automation based on Zigbee sensor status when WIFI network is down? Since now all Zigbee devices are communicated via MQTT, despite can see Zigbee logs using external monitor.
You need to understand tcp/ip networking a bit better. If one process on a host wants to communicate with a service running on the same host, they communicate via the localhost address which requires no Ethernet, either wired or wireless.
