Replies: 30 comments 21 replies
-
|
@tlpbu The camera was tested with Hypfer firmware on S5 and V1.. there was no issue during the tests I did before releasing it. |
Beta Was this translation helpful? Give feedback.
-
|
Will try ASAP |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunatelly will not be so quick for me to verify because HACS isntallation dies not applow to select version as it is show in instruction - latest version is always installed. |
Beta Was this translation helpful? Give feedback.
-
|
Okay I just did a fresh install of the Camera for my V1 and on RPI4 no problem with 1.5.7 for instance on my test environment I do currently have a beta release of the OS on it. From the logs anyhow it looks like you had an issue with the internet connection those errors for instance occurs when HA isn't able to get the connection to the store. |
Beta Was this translation helpful? Give feedback.
-
Sorry, I can't get what do you mean with "HACS installation dies", it looks you have some internet connection issue. I just deleted all entities and removed the installed camera, then reinstall and setup all again and it did work also with 1.5.7, when you select an older version HACS need a little of time (the selection filed is grey and after a while it become again white -> editable). Then you can press download. If all of above do not work you can always try the manual installation method. I will help you to troubleshoot this (not sure if it is actually a camera issue at this point).. I would advise you reset your modem and then try again. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, autocorrect probably. Rephrased below.
Unfortunatelly will not be so quick for me to verify because HACS installation does not allow to select version as it is shown in instruction - latest version is always installed. |
Beta Was this translation helpful? Give feedback.
-
|
Did a fresh setup of the camera again just to double check
Upss okay this happens because of the new UI of HACS, if you press download then there is the possibility to select the version by the way I try again to remove all and setup as scratch 1.5.7 and it did work on..
@tlpbu please try once again to setup 1.5.7 with HACS.
|
Beta Was this translation helpful? Give feedback.
-
|
So I just did reinstall v1.5.7 carefully step by step with integration debug enabled. Managed to reproduce the issue yet root cause is slightly different - this has something to do with handling multiple vacuums because starts to happen only once I add second vaccuum (which as per readme is supported). In first attempt I quicky added both vaccums to integration at once so did not consider it as a reason. All I can get from logs in hurry before HA restarts again: |
Beta Was this translation helpful? Give feedback.
-
|
Removed second vaccuum from integration and HA restarts loop stopped and camera for first vacuum works so this definately is the root cause. Updated bug title for future reference. |
Beta Was this translation helpful? Give feedback.
-
I tested it with two vacuums too.. so now we need just to understand what it is happening in the background. So far I see from the logs looks all okay.. but I will need some time and more details will come back to you soon 😉 |
Beta Was this translation helpful? Give feedback.
-
|
@tlpbu Home Assistant have a backup of the log file in the config folder. Do you have a file editor or vscode if not Samba on your home assistant instance? If you have one of those should be possible to download or simply copy the entires from the PI4 (using the web browser) the file home-assistant.log.1 should contain the errors or data we need to conclude what is happening. Additionally there's also an home-assistant.log.fault file that you could check to see what caused the restart. |
Beta Was this translation helpful? Give feedback.
-
|
I changed system wide logger to debug level to and added secont vaccuum to integration to reproduce reboot loop. However nothing suspicios was logged moments before restarting. I doubt Wild guess is maybe this is related to insufficient memory 4GB on RPi4 when it has to process 2 vacuums data. My experience is that if something cannot be logically explained it lack of RAM of storage. |
Beta Was this translation helpful? Give feedback.
-
|
I use 8GB version of the PI4 and 4GB isn't really recommended for Home Assistant in general so far I know. |
Beta Was this translation helpful? Give feedback.
-
|
This is tough issue since nothing apparent is logged as error. I did couple more experiments and narrowed down the problem - it is not so much of an issue with handling multiple vacuums but rather specific Dreame D9 Pro vacuum which I always added as second one in addition to working Roborock V1. This time I removed working Roborock V1 integration and then added Dreame D9 Pro vacuum as the only one and sure enough HA reboot loops started. Logs in debug more show nothing hinting: |
Beta Was this translation helpful? Give feedback.
-
@tlpbu I can't see were is the problem and again I would need the full logs of this "issue" you are reporting if you are willing to share it to me I will gave you an email address. In general two vacuum can run but this is the current consumption of the camera with both vacuums one in segment clean and the other in zone clean.
No issues to start both cameras for instance on this configuration. I'll try to buy a PI3b+ and use that to gain the specs we need. |
Beta Was this translation helpful? Give feedback.
-
|
I propose we skip RPi performance hypothesis at least for now and thus save money on buying PI3b+. As I mentioned in previous comment I think somehow problem lies in specific vacuum Dreame D9 Pro. Seems strange to me since technically integration is with same thing - Valetudo but I simply do not know how integrations is implemented. |
Beta Was this translation helpful? Give feedback.
-
In the wiki section there is an explanation of how the camera works.. the D9 works so far I know well. I did had from other users reports that somehow mqtt is getting wrong the configuration of the vacuums.. apparently reinstalling the MQTT add on did help in that cases. The camera is waiting for the mqtt payload with the map_data of then the mqtt is unzipped and the json is processing with numpy an image array.. I'm a little busy right now personally but we solve this.. |
Beta Was this translation helpful? Give feedback.
-
|
No hurry. BTW did thorough comparison between both vacuums and despite both having same latest Valetudo 2023.12.0 installed there is one notable difference on Dreame D9 Pro - it has |
Beta Was this translation helpful? Give feedback.
-
|
I am now fairly confident failure leading to HA reboot loops is somehow caused by inability to parse messages content in
|
Beta Was this translation helpful? Give feedback.
-
I can delete one of the topic and probably reproduce the phenomena you faced, it this is the problem then I can fix it quite easily, thank really much for you assistance in this trouble shooting... as soon I will release the new patch for this issue will close it or let you know. I will change the subject because this shouldn't be related to the specific model of the vacuum. |
Beta Was this translation helpful? Give feedback.
-
|
Just to clarify Missing map-data topic of the vacuum does not cause Ha reboots are new bug title says. If there is not such topic in MQTT broker HA behaves properly excepts camera not having any image of course. |
Beta Was this translation helpful? Give feedback.
-
|
Then you need to reinstall/recofingure the broker just to be sure.. https://community.home-assistant.io/t/valetudo-vacuums-map-camera-for-home-assistant/600182/51. Anyway first... see below.
If this is persisting try to change the topic of the vacuum to something completely different it should start with valetudo / vacuum_D9_Servantess.. remove the camera first please and then set it back as soon the vacuum is setup and map data should be already there (no need to change that), then add the camera for the D9_ Servantess.. and let's see what happens.. |
Beta Was this translation helpful? Give feedback.
-
|
@tlpbu I'll move this to discussions at this point we concluded that the camera isn't guilty.. for the restart if you agree. |
Beta Was this translation helpful? Give feedback.
-
|
@tlpbu how it goes have you solve the setup issue of vacuum? I would really appreciate if you can possibly share if you had any other issues or solutions. |
Beta Was this translation helpful? Give feedback.
-
|
I did change vacuum identifier in Valetudo MQTT connection settings hence it was considered completely another device by HA so all entities were created new by HA yet it was still the same problem. Summarizing I thing this is some problem in parsing map-data messages content. Can we somehow test it by passing exact message to some unit/ integration test or during debugging? |
Beta Was this translation helpful? Give feedback.
-
|
Tried to install v.1.5.5 via redownload but after version selection from dropdown it is anyways switching back to latest v1.5.7. Transitional changes in HACS are maing such experiment much harder and timeconsuming. Will try again in weekend |
Beta Was this translation helpful? Give feedback.
-
|
On the drop-down list of HACS select v1.5.5 and wait for a second, then press download. There's no service for downloading the camera from home assistant, this is a custom component (by definition it comes as it is).. anyway.. I am flying back home today and I should have some time to check out your vacuum data. When you go on the camera options there's an option to export the log as zip file. This zip file has the same name of your vacuum.zip. If you are using SAMBA just copy or move this file to your desktop, inside the zip file there should be a JSON file. If not then the camera didn't get the topic.. that by the way is the camera attributes.. if you have a file editor or vscode you can download the file (snapshot docs). The JSON would give a clue already if the camera got the data or not. No json = no data from the vacuum = grey image. If there's an error on parsing the data as you suspect normally the camera generates a warning on the logs. If something isn't clear I would be happy to clarify. |
Beta Was this translation helpful? Give feedback.
-
|
@tlpbu the download of 1.5.5 didn't work also for me but 1.5.6 should be okay as per it do not use threads as 1.5.7 do (this is the big change I made). The important thing is as mentioned above the logged data from camera side, from the D9. If there's no logs (that should be in .storage when the update cycle end at init) When it starts the camera do:
If the camera do not receive the payload it will output the last image if available or a gray image. And all of this is logged as well managed by try and exceptions that will check for any errors during the conversion. It works like that since the beginning and it is bulletproof. You can check the code by yourself if you wish. Anyhow as I do not really understand what it is going on in your instance. Honestly without the data I requested it would be also difficult to support it. There's a discussion here and it was confirmed that even if at slow frame rates the vacuum could be rendered on a PI3b+. I tested the camera with two vacuum and no issues (8GB home assistant operating system environment and all updated to the latest). I hope in your kind understanding will be happy to help you resolve this whatever is the reason. |
Beta Was this translation helpful? Give feedback.
-
|
It was not possible to installe older version via HACS redownload option so I completely uninstalled Valetudo Vacuum Camera on HACS and installed v1.5.6 via manual install howver after restart of HA and adding Dreame D9 Pro (IMHO D9 without Pro is different model - maybe is important diff) entity id to integration HA reboot loops started again :( Do not find any logs in Could be nothing is persisted just because HA reboots. Very sad we are left blind as a result. This HA instance is live systems so for now I am competely removing Valetudo Vacuum Camera custom component. All the logs I have: Maybe |
Beta Was this translation helpful? Give feedback.
-
|
I didn't catch if the reboot happens when you use the D9 or you setup the camera for the D9.. can you please clarify? EDIT: Log entry "Robot is in None" = no rooms names are defined = the robot is a room that you didn't named.. so the camera will continue with the image creation.
Below are the camera attributes that you should see along with the calibration data, the json_data: Success = the image rendering is going to be processed. No calibration or Room some error occurs. "Developer Tools" filter camera.. in "states" meanwhile I will try the same procedure, I mean to mess the Topic Prefix with the entity id of the vacuum in MQTT, that by the way.. it isn't a problem camera wise as per we get the topic from Home Assistant MQTT directly.. [x] de facto and please confirm you get the images from the V1 is that correct? Thanks a lot for your understanding and cooperation, I hope this can help us both to understand what is going on.. and P.s. if none of the above works you can always try ValetudoPNG. |
Beta Was this translation helpful? Give feedback.
-
Done.. and also with "vacuum" as Topic Prefix no problem on my PI4.. note I had to put both Topic Prefix and Idetifier for HA to recognize the vacuum.. and the camera was deleted for valetudo/GlossyHardToFindNarwhal as the entity in the MQTT.. the card of course was setup with the new camera after vacuum/GlossyHardToFindNarwhal was discovered from MQTT. So no problem with MQTT, no problem with the camera..and of course with the vacuum firmware for instance on S5. If you post a json of the D9 Pro from the browser yourvacuum/api/v2/robot/state/map (valetudo rest api) I car run it on my test environment to check if there is any problem parsing the data.. thanks once again. |
Beta Was this translation helpful? Give feedback.
-
|
Made also some additional tests and renamed the vacuum.. this of course cause also the camera to be renamed.. there we need to confirm of course that it is okay.. then changed the camera entity id the card and all works.. @tlpbu I would really appreciate the json data from the D9 (your_vacum_ip/api/v2/robot/state/map) so that I can confirm if there is an issue on parsing the data or not. If there is an issue on this.. of course I will trace it like a camera issue. If anyone else using Dreame D9 Pro would confirm would be nice (help wanted here) It looks that MQTT should be okay I couldn't for instance found a problem on it on my tests.. would also advice you check your MQTT with MQTT Explorer this can give you the possibility to clean up MQTT from the removed entries not in use anymore and also give you a better understanding if the vacuum is properly setup in MQTT. |
Beta Was this translation helpful? Give feedback.
-
Other than that D9 Pro vacuum is used in HA daily for years and is configured simlarily to Robock V1 vacuum which works fine in Valetudo Vacuum Camera. D9 Pro Valetudo MQTT connectivity long time settings: I also tried deleting vacuums topics from MQTT broker but it did not help. |
Beta Was this translation helpful? Give feedback.
-
|
Was also at some point suspecting that upper-camelcase MQTT topic identifier is screwing things up and did change it to lower_underscore topic identifier (as you had in integrations tests) but it was not root cause. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
@tlpbu tested and the map is output without any issue (if you want I can show you the result). Also loaded via home assistant the json was rendered below the when the image is output. |
Beta Was this translation helpful? Give feedback.
-
|
On notable difference see here is that my machine it aflways logged no further than I never saw this line logged for D9 Pro Maybe around that code some extra debug level logging can be set up. |
Beta Was this translation helpful? Give feedback.
-
|
Well it also means that MQTT isn't the problem as well the json parsing... I can post the image as I wrote earlier with your consent. |
Beta Was this translation helpful? Give feedback.
-
|
@tlpbu how much memory you have available on your PI4 from the 4GB in the max load time? The camera currently need at least 0.54GB available for each vacuum this is around 1.08GB that is 1/4 of the memory of your device. I'm trying of course to improve this memory consumption but I'm not sure how long it will take. I will add some additional safe guard and also as you wrote logging hopefully within tomorrow I will let you know as soon I'm done. I think I catch now were is the problem you described.. the camera should work with your D9 Pro as well.. I'll covert back this discussion as an issue.. and add some more integrations to the PI4 were I test the camera in order to make it more.. challenging ;) appreciated the time you have spent to help me troubleshoot this issue. |
Beta Was this translation helpful? Give feedback.
-
mmmmm really? then give me a couple of minutes and let me check how we can avoid this and catch were is the problem. Thanks a lot for the info. Edit:
There are other options such as ValetudoPNG if you feel confident to use it please do, anyhow please also be so kind to wait until we can confirm that whatever it is happening and HA do not restart when you setup the camera.. this mean within the next release would be really appreciated if you would give it a try. |
Beta Was this translation helpful? Give feedback.
-
|
@tlpbu added a video showing that is possible to render two vacuums at the same time on issue #74 this is just to be 100% clear ;) |
Beta Was this translation helpful? Give feedback.
-
|
To avoid wrong conclusions a I would like to reiterate (#73 (comment)) that this is not about multiple vcuums handling. HA reboot loops start also if Dream D9 Pro is to added to valetudo_vacuum_camera as the only vacuum. |
Beta Was this translation helpful? Give feedback.
-
|
The D9 should work I don't believe it's a problem but I guess also if it was a different model.. it could not work on your system.. |
Beta Was this translation helpful? Give feedback.
-
|
Actually it does work in my HA instance for another my vacuum Roborock V1, problems only when Dram D9 Pro is added (even without Roborock V1 being added) |
Beta Was this translation helpful? Give feedback.
-
|
Okay just to avoid you miss understand my previous post.. the camera will overlap NP arrays for the number of segments (rooms) each array is around 100Mb from a calculation I made but I still need to verify it.. also it is important to know the CPU as shown in the video, operating HA sometimes have peaks up to 100%. Now the V1 of course works on your system as per the V1 is using one floor data only (no segments) also the V1 will not process the room position data (as there is no rooms available).. while for the vacuum as the D9 Pro you own.. that once again and as you can now also see can be rendered.. without any problem..
have to process the rooms data. Note the image come from a the same image handler used on the camera and as I wrote above I imported the same json you provided in the PI4 and render it as well twice (once per each camera installed on the test environment). Apparently your system stop when a copy of the array with the segments is done or after that.. so.. I'm forcing the garbage collector of python to free the memory after the overlap is done and also the image handler will go ahed only if 3 times of the calculated memory required is available, else will return a none image = grey image as no image can be prepared.. I will add also some other check, to check the auto_trimming of the image for exceptions to make so that HA will just Error but not restart and eventually give us an hint on what is the problem on this specific case.. hopefully this can help to understand better the direction I'm taking to solve this issue you rightly raised. |
Beta Was this translation helpful? Give feedback.
-
|
@tlpbu as discussed v1.5.7.1 is published and contain what above not mentioned in the RN that I will adjust later.. if the CPU goes over 80% but the first image for instance must be created the camera will return the last image without processing. |
Beta Was this translation helpful? Give feedback.
-
|
@tlpbu once you have downloaded the v1.5.7.1 (that normally) I wouldn't publish as release (I did considered you had a lot of problems with HACS) please let me know.. as I will need to revert the changes made with GB and also.. well, implement some new code. The 1.5.7.1 is a kind of trap version.. for the specific case.. so please let me know what is the result and especially if you completed to download it. |
Beta Was this translation helpful? Give feedback.
-
|
@tlpbu |
Beta Was this translation helpful? Give feedback.
-
|
Didn't get any feedback here this discussion is getting closed. |
Beta Was this translation helpful? Give feedback.
-
Checklist
The problem
After fresh installation of Valetudo Vacuum Camera and restart on HA on RPi4 constant Home Assistant reboots start as soon as Vacuum device id is set in integration setup form. This unfortunatelly makes Valetudo Vacuum Camera unusable.
Luckily there is ~15 sec timeslot when HA has loaded enough to be able to access /config/integrations/dashboard and delete Valetudo Vacuum Camera integration. Then reboots stop immediately.
Nothing specific can be observed in HA logs execpt most likely unrelated:
What version of an integration has described problem?
v.1.5.7
What was the last working version of an integration?
No response
What vacuum model do you have problems with?
Dreame D9 Pro
Please firmware installed on your Vacuum.
2023.12.0
What version of Home Assistant do you use?
2024.1.5
What type of installation are you running?
Home Assistant Supervised
Camera's settings.
No response
Logs or Errors shown in the HA snapshots (please enable the Debug Mode)
No response
Additional information
No response
Beta Was this translation helpful? Give feedback.
All reactions