You can do privileged mode or does just docker run --device=/dev/hidraw<number> .... work?
My HA is just in privileged mode though since that seemed like the default.
1 Like
I’m currently running gosense but if you are going to try to get yours incorporated into core I may as well switch now and do away with the mqtt requirement. I’ll go ahead with privileged mode.
1 Like
@atomicpapa, I am currently running docker. Host is ubuntu. What is your host OS? I can share my home assistant docker section.
running Ubuntu 18.04 as my host system. Thanks!
@atomicpapa, hope this helps.
home-assistant:
image: "homeassistant/home-assistant"
container_name: "home-assistant"
restart: unless-stopped
volumes:
- ${USERDIR}/docker/home-assistant:/config
- /var/run/docker.sock:/var/run/docker.sock:ro
- /mnt/media/Podcast/Home Assistant:/podcast
network_mode: host
devices:
- /dev/ttyUSB0:/dev/ttyUSB0 #Linear HUSBZB-1
- /dev/ttyUSB1:/dev/ttyUSB1 #Linear HUSBZB-1
- /dev/hidraw1:/dev/hidraw4 #Wyze Sense Hub
environment:
- PUID=${PUID}
- PGID=${PGID}
- TZ=${TZ}
depends_on:
- mqtt
I used the following command to detect which device was the wuze sense:
dmesg | grep hidraw
Super easy setup, thanks to everyone that worked on this.
I added a template sensor for the battery level that I wanted to share.
First time I tried to make one so I’m not 100% sure if the code is correct, but it works fine on my setup.
- platform: template
sensors:
laundry_room_battery:
friendly_name: 'Laundry Room'
value_template: "{{ state_attr('binary_sensor.wyzesense_7xxxxxxx', 'battery_level') }}"
unit_of_measurement: '%'
device_class: battery
4 Likes
@kevinvincent, I created a pull request for an additional step to help detect which hidraw the wyze bridge is using.
Just a small tip, you can get rid of all the icon_template: stuff and replace it with device_class: battery instead.
It does the exact same stuff as the icon_template but saves like ~20 lines of code. Just makes things a bit cleaner, especially if you plan to add more template sensors.
1 Like
Cool thanks. At one point when I compared this sensor to my other ones I thought “it would be nice to be able to set the sensor type” but I had no idea how to do it. Time to simplify the code. I edited the original post.
1 Like
Wonderful work! Thank you!
I wish I knew golang so I could help. One of the few I’ve never bothered to learn. Maybe now is the time.
Regardless, it’s working perfectly!
@MediaCowboy thank you! I’ll take a look at the changes when I can get back to my computer on Monday and pull them in
The entity will always represent the true type of sensor, however you can customize how it appears to home assistant using this method https://www.home-assistant.io/docs/configuration/customizing-devices/
Just change the device class as you’d like.
I hope this helps others.
5 Likes
Don’t know if it’s just me, but I updated to latest version of ha-wyzesense through HACS (d4079eb) and now none of my sensors are showing up. The entity ID’s seemingly never show up, it’s like it’s not loading at all. I am running Hassio on a RPi3B+ with latest stable version of HA. Didn’t touch the Wyze configuration or basically anything else today, besides updating HACS to v13 and WyzeSense to latest.
And unlike other integrations in HACS this doesn’t seem to use versions/releases so there is no way for me to roll back to the previous version (through HACS at least).
It was working perfectly fine a few hours ago and I was even saying in Discord and Reddit that I had no issues, so I guess I jinxed myself haha 
Love this integration and all the work @kevinvincent and HcLX did. Amazing job! Had to do proper video after the live stream as it was just too good. I’m all about the DIY and doing the ESP8266 thing with PIR sensors without batteries but wow, these are stupid simple and just work.
2 Likes
The only that was made was to the readme file. I am upgrading now to see if there is an issue on my end.
Update:
@SeanM, I just finished the update and all my sensors are working.
Thanks for checking, I’ve got it working now after a few more restarts (knock on wood). One time the motion sensor showed up but not the contact sensors, which was kinda weird. Not sure what caused this seemingly out of the blue, but I posted my logs on Kevin’s Github repo.
On a side note, I didn’t realize that majority of the updates through HACS were solely for minor changes to the readme file, I could’ve saved a bunch of unnecessary restarts (kinda time consuming on my Pi). Thanks for pointing that out as well 
Makes me wonder if this isn’t related to hassio. I am running Ubuntu 18.04 on some beefy hardware and then the docker version of home assistant. I know I saw Kevin post on github that there may be issue with the alpine change for hassio and this component.
@SeanM So the motion sensor showing up but not the contact sensor is a built in recovery mechanism. Basically when the component starts up it tries to get a list of paired sensors and add them to HA with the last known state. It is technically okay if that fails (your sensors will just show unavailable). However whenever the sensor triggers, it will be added to your entity list and updated to the correct state even if the first step fails. Basically what happened in that case is the sensor listing at the beginning failed but at some point it got an event from the motion sensor and added it the list when that happened. The same would have occurred for the contact sensors if they were triggered.
I have some thoughts on how to increase the reliability. I may send you a modified copy to test it out if I can’t reproduce it on my end tonight.
Also I have yet to update to the latest alpine linux based container but I will get to that tonight and report back.
EDIT: Looks like hass.io has always been and will continue to be based on Alpine Linux. As a result, nothing is changing there so it can’t be that.