Posts made by rafale77

@sender

Yes you can. I don't know what this entire obsession with containers is about in the home assistant forum. I found it actually much easier to install and manage with a VM or a virtual environment. By the way, the supervised installation has had an attempt for deprecation causing a huge thread on their forum. A lot of people use it but it is so complicated and takes so much work to maintain that the devs wanted to take it away... also because IMHO it really made 0 sense to begin with.

Disturbingly the simplest, fastest, most flexible and easiest installation is the one they recommend for developers:

Home Assistant

Installation in Python virtual environment

How to install Home Assistant in a Python virtual environment.

In my case, in a ubuntu VM, I even skip the virtual environment which is an unnecessary added complication.

Make a copy of your home-assistant configuration folder. (If you don't want to start from scratch)
Set up the VM to the same address as your previous installation.
Just install a virgin ubuntu OS, install python3.7 if it isn't already installed, this will depend on the version of ubuntu you installed. I think any version before 20.04 will need it:

sudo apt-get update && sudo apt-get install python3.7

Copy your old .homeassistant folder into your user directory again only if you want to keep your config.
Install home assistant from my repo

python3.7 -m pip install git+https://github.com/rafale77/core.git

and start it:

hass --open-ui

You can go through another tutorial to make it auto start upon VM start but this should suffice for now.
I would argue that this isn't any more complicated than the supervised installation. To me it is actually much simpler... It is literally 3 commands in the worst case for a new install, without any funky docker software to download.

The docker container, I think helped people setup the autostart and install the right version of python... A complicated solution to a simple problem. Adding another layer of management program, virtualization, restrictions, file system management, cpu and memory inefficiency etc... just to control 5 lines of startup code?

Yeah I look at things from an overall standpoint... Yes it may appear simple at the surface but it is actually very complicated just one layer underneath so if one wants to do anything more with it, it becomes a hot mess. I use some containers but only for very small and limited applications which benefit from being self contained. For anything more than that... like home-assistant, I just find it absurd.

And yup, privacy... again why I am not running anything like this through a cloud API...
Another example of something made simple but using a very complex solution under the surface to a simple problem. I see the cloud as philosophically the same as the docker containers... Adding layers of complexity and liabilities for the sake of making it convenience.
I am a big advocate of KISS but from an overall standpoint. Not from just the user installation which is only a short one time extra effort vs. a lifetime of inefficiency and other risks.

@sender

One idea I just had to simplify things is just to install home assistant from my branch by doing this from a venv:

pip3 install git+https://github.com/rafale77/core.git

But again it does not help the containerized installation which has the disadvantage of its benefit: Contained controlled small environment so you cannot mess with it means that you can't modify anything in it.

if Microbot.is is what you are talking about... their whole business model is to get clients to rely on their clown servers for a price to actuate a button pusher... not a fan of the concept. Maybe replace the button with a your own button which would have a zwave relay?

SwitchBot Smart Switch Button Pusher - No Wiring, Wireless App or Timer Control, Add SwitchBot Hub Compatible with Alexa, Google Home, HomePod, IFTTT: Amazon.com: Industrial & Scientific

I am not seeing a serial number but have a UUID which I assume is unique and a subvendor ID of 0x0115

True, it is a bit dissuasive at first... And the firmware map is kind of mind-blowing and takes some time to understand how it works. Well sorry you got these 3rd party buggers.
This I am pretty sure where I got mine from. I would recommend returning those amazon ones if you still can.

Z-Wave.ME UZB Z-Wave+ USB Stick US Version - Free shipping

This stick works with all certifi ed Z-Wave devices regardless of its vendor or date of origin. The Sigma Designs Serial API specifi cation is available to all owners of a Sigma Designs Z-Wave SDK. You can however upgrade the stick to accommodate this function using licensing key.

I am also not using the GUI. I use the command line upgrade tool, in part because I had a lot of failures with the GUI with not much explanation... and I like to know what is going on...

Have you tried unplugging and plugging it back to power cycle the stick? I screwed up the firmware upload quite intensively on the last upgrade (>50x) due to some memory indexing issues and never managed to brick it. The process has it load the entire firmware image on the non volatile memory first and then after checking it is corruption free, it does the upgrade. I found it much more difficult to brick than say the vera firmware. The 3rd party vendor stick is unknown to me as I don't have one but I see some people struggling with upgrading those.
I am running on 5.39 at the moment...

@SweetGenius

I got my stick from eBay I think but I think amazon one here should be upgradable. The non upgradable ones are more rare I think:

Z-Wave.Me USB Smart Home Stick made for My Cloud2 by WD, Z-Wave Plus - - Amazon.com

Just remove the repo from your apt list.

How to apt-delete-repository?

I would like to run the reverse of this command to remove the non-compatible repository in Debian 8.1 sudo add-apt-repository -y ppa:nemh/systemback where the command add-apt-repository is in the

I recommend not using apt to install z-way anyway. It is never quite up to date.

Unfortunately, I can't help much in this case. Using the supervised installation means you have everything containerized and I am a bit allergic to this approach as it complicates the interaction between containers and makes access/changes to various code very difficult. It also an inefficient installation mode. These changes are not addons. They are core code changes which will require any installation but the supervised/containerized ones.

In my pursuit of efficiency, for home assistant, I have dug deeper into its image processing and camera code and found that image processing, not being the camera component's main intended purpose is extremely inefficient and can generate 3x more CPU load than needed. Essentially it is doing way too much format coding/decoding:
From the camera's stream H264/H265 to raw then to JPEG then to bytes then to raw then to array for processing. I found it to be insane and decided recode this:

These two core component files need to be replaced:
"https://github.com/rafale77/core/blob/live/homeassistant/components/camera/init.py"
"https://github.com/rafale77/core/blob/live/homeassistant/components/image_processing/init.py"

Then the ffmpeg integration component:
"https://github.com/rafale77/core/blob/live/homeassistant/components/ffmpeg/camera.py"

And finally the two image processing components, opencv (object detection) and dlib (face recognition) which I also streamlined:

"https://github.com/rafale77/core/blob/live/homeassistant/components/dlib_face_identify/image_processing.py"
"https://github.com/rafale77/core/blob/live/homeassistant/components/opencv/image_processing.py"

For the last 3 files, comment out all the lines containing Cuda if you do not have a GPU.

How to:

Replace all 5 files I have posted above into your home assistant installation.
Configure your cameras as ffmpeg components as you normally would. If it uses h265 encoding, add "h265" to the "extra_command" option. No other extra command is needed or works.

Get the model files and create a "model" folder in your homeassistant folder (it should be ~/.homeassistant).
Here are the model files:
"https://github.com/mmilovec/facedetectionOpenCV"
You only need the res10_300x300_ssd_iter_140000.caffemodel and the deploy.prototxt.txt files.
and why I picked this model for detection.
"https://www.learnopencv.com/face-detection-opencv-dlib-and-deep-learning-c-python/"

Next the object detection model files:
"https://github.com/AlexeyAB/darknet/releases/tag/darknet_yolo_v4_pre"
You only need the first two files. (.cfg and .weight)
and last, this file , which you will have to rename cococlasses.txt. It is the list of objects the detector can identify which you can use for your configuration below. By default it will detect "person"
You should have a total of 5 files in the model folder if you want both face recognition and object detection. Now configure these components in yaml as per the official documentation and you are done. For object detection, the "classifiers" option is a comma separated list: i.e. "person,car,dog". Homeassistant's image processing component has you set the update frequency.
These should work fine on a couple of cameras on a CPU but the higher the processing frequency is and the more cameras you have, the higher the load. I have mine update at 5Hz, meaning using 0.2s interval and I run these on a GPU, now with 7 cameras. No more camera motion trips due to the wind blowing on leaves... etc... and yeah it's completely integrated into openLuup.

It is pretty straightforward if you know where your installation is. If you use a virtual environment, bare metal or VM installation, it should be easy to find the location of your python packages. If you use containers then I cannot help you.
Once you the location of your home assistant package, it is as easy as replacing the original file with my version and setup the component the same way as the original one says. For these, you will need to download the models which are publicly available in the links I posted and then put them into a model/ folder in your home assistant configuration folder. ".homeassistant/model".

Edit: pretty thrilled with the possibilities: Counting cars in the driveway/garage counting people at the door to adjust the greeting message... etc...

@therealdb

Thank you! I will be testing it shortly now that I am done with my object recognition component and fixed a couple of network issues.

I got to what I think is the final solution, having switched to the YOLO v4 model which is only 3 months old:

AlexeyAB/darknet

YOLOv4 - Neural Networks for Object Detection (Windows and Linux version of Darknet ) - AlexeyAB/darknet

and running it through opencv, the updated code is in the link in the previous post.

I was also thinking about using a proxy for this but it is really adding a layer of complication. For MQTT it might be work it though, I think @therealdb 's solution is likely a better approach... basically also kind of a proxy written in C to act as the client and seems to be very lightweight.

So I got a bit frustrated with the resource drain from Watsor's usage of FFmpeg and have been investigating various models to implement on openCV. I ended up completely rewriting the Home assistant openCV component to use an updated SSD512 model and using my own FFmpeg component for decoding... which uses openCV:

rafale77/home-assistant

:house_with_garden: Open source home automation that puts local control and privacy first - rafale77/home-assistant

@akbooer
Or it could very well be that I missed something but looking at reports from github, I am not the only one observing it. These library work very well for publishing to the broker. They don't work unless you want to dedicate an instance of lua to be the listener...
@therealdb
This could potentially be the base for a bridge to so many things for openLuup!!

And... it is done! My outdoors IP Cams no longer just detect motion... They detect people, packages, and cars and are now used as openLuup scene triggers!

Update: I now have a kind of a working solution and it is interesting...
The fundamental problem is that setting up an MQTT client to listen to the broker blocks the luasocket and therefore openLuup.
The two libraries use different approaches to the problem.
The older library used by the vera MQTT plugin uses a handler function which polls the broker and gets and closes immediately regardless of getting a message or not. It therefore won't block the luasocket but it comes back empty 99% of the time and really relies on luck to catch a message as it can miss them. Basically unusable.
The newer lua library does the same but waits for a message back and blocks the luasocket while waiting. If one sets a high polling frequency without getting a message back, openLuup hangs. My solution to this has been to significantly increase the frequency of messages from the publishing client to unblock the socket. It really is no longer event based and this generates a lot of traffic.

If anyone has better suggestions (@therealdb I look forward to your bridge). I am also thinking that openLuup could use moving all its http traffic from luasocket to libcurl...

Edit:

I ended up giving up on trying to make it work with luasocket and spent 2min setting up 4 MQTT subscriptions on Home Assistant and another 10 to build the bridges back into openLuup. I really hoped to be able to do have a direct pipe into openLuup...