Open auanasgheps opened 2 years ago
Rendering map on server side uses too much cpu and takes some time with python
Yeah, that's why maps generated by Map Extractor usually have a small resolution. Buuuuuut the map itself has quite low resolution as well, so it doesn't change that much (just overlays). Server-side rendering makes it possible to use map image in other places, not just a dedicated card (contrary to Valetudo map card approach), but also in notifications, built-in cards and others. There was an attempt to use a faster rendering library (instead of pillow), but right now I don't have time for migration.
Rendering map on server side uses too much cpu and takes some time with python
Yeah, that's why maps generated by Map Extractor usually have a small resolution. Buuuuuut the map itself has quite low resolution as well, so it doesn't change that much (just overlays). Server-side rendering makes it possible to use map image in other places, not just a dedicated card (contrary to Valetudo map card approach), but also in notifications, built-in cards and others. There was an attempt to use a faster rendering library (instead of pillow), but right now I don't have time for migration.
Yes, actual map and map objects can be rendered very small and upscaled easily but i cannot scale down the icons and texts to match the map size. Thats why i decided to render map very large for preventing icons being distorted but that is taking too much processing power now (i am concerned with the rpi users right now). App uses dynamic scaling of these object according to map zoom to solving that issue but if i do that, single icon will cover complete room on my map. I have also checked the other image processing libraries but implementing one of them is too much work and time for me too. Maybe i will render the base map on server-side, icons and texts on the client-side at the end, like you did.
@PiotrMachowski can you please tell if the Map Update described here applies to Dreame vacuums via MiioT integration?
If it does apply, the blueprint to disable map update when the vacuum is not used should be changed to include the state "idle", used by Dreame via MiooT. If it does not apply, let's change the section text.
@auanasgheps It should apply to all vacuums, but it's not possible for me to know all possible statuses in all integrations.
Keep in mind that purpose of this blueprint is different than handling situation described in this issue.
@auanasgheps i have released my new custom component for Dreame vacuums with map support.
You should check it out https://github.com/Tasshack/dreame-vacuum/
@Tasshack great work 👍 You might want to add your integration to platforms supported by the Vacuum Map card. By the way, the card now can automatically get a list of rooms to clean in vacuum_clean_segment
template using a button in the editor.
@Tasshack great work 👍 You might want to add your integration to platforms supported by the Vacuum Map card. By the way, the card now can automatically get a list of rooms to clean in
vacuum_clean_segment
template using a button in the editor.
Yes i will add this to the supported platforms of vacuum map card but there is a problem with the automatic generation of the room ids. New version of the map card generates room ids from rooms array index which starts from '0' but Dreame uses segment ids starts from '1'. Because of that generated segment ids wont match with the actual segment id on the map data. Also Dreame does not use deleted segment ids on new created segment. This means it is not guaranteed that the array index will match the segment id. Is it possibe to you get the segment id from room attibutes if exists?
@PiotrMachowski I have already checked the code but i think i didn't saw that on first time, sorry about that.
I will change the segment_id
key to room_id
on my code and that issue will be solved.
Thanks.
@Tasshack by looking at the screenshots I don't like it at all... I love it! Will test it soon.
Will discuss in your repo.
@PiotrMachowski what should we do with this issue? I have implemented the automation some time ago and works very well. If this can't be added in your integration, shall we document it maybe with a blueprint and call it done?
auanasgheps Are you still against the integrations not build with python-miio after seeing my project? You have to admit that integration which is tailor made for specific device always will be better than an integration is trying to support all available devices. I am not against that libraries or integrations but developing just for a specific device has lot of advantages on the development side of things.
@Tasshack I am astonished by the amout of settings available. Definitely great job that deserves the praise!
I am "against" small integrations because they can be abandoned easily and HA evolves so quickly. python-miio is one of those large integrations that will never be abandoned... but I hope yours will get the visibility it deserves! I'm gonna try it very soon.
@auanasgheps i have released my new custom component for Dreame vacuums with map support.
You should check it out https://github.com/Tasshack/dreame-vacuum/
Will this work with the Dreame D9 (p2009)?
@auanasgheps i have released my new custom component for Dreame vacuums with map support. You should check it out https://github.com/Tasshack/dreame-vacuum/
Will this work with the Dreame D9 (p2009)?
D9 is pretty old compared to other supported devices but i don't actually know it the answer of your question. Theoretically it sould work, if the D9 is using same Mi Home plugin with the Z10 or L10. It should definitely work without the map feature but i didn't want to include it on supported devices list without a working map since there are alternative integrations available without map for D9. If you are willing to test it you can create an issue then i can provide a branch that you can add D9 from config flow.
@auanasgheps i have released my new custom component for Dreame vacuums with map support. You should check it out https://github.com/Tasshack/dreame-vacuum/
Will this work with the Dreame D9 (p2009)?
D9 is pretty old compared to other supported devices but i don't actually know it the answer of your question. Theoretically it sould work, if the D9 is using same Mi Home plugin with the Z10 or L10. It should definitely work without the map feature but i didn't want to include it on supported devices list without a working map since there are alternative integrations available without map for D9. If you are willing to test it you can create an issue then i can provide a branch that you can add D9 from config flow.
Good. I'll give it a try when I'll have some free time. Thanks
I'm currently using dreame x20 pro plus is there any way to down grade dreamehome app or bypass regional lock? if so, please help me to do so..
Also me I have a Dreame x20 pro plus and I cannot find a way to work It. Can you help on some way?
Also me I have a Dreame x20 pro plus and I cannot find a way to work It. Can you help on some way?
You should install the latest beta https://github.com/Tasshack/dreame-vacuum/releases/tag/v2.0.0b8
Thank you for the file but there is a description of the procedure that I need to do to use this program? I'm sorry I'm new to this 😄
https://github.com/Tasshack/dreame-vacuum/releases/tag/v2.0.0b8
Just for clarification, by installing the beta you should be able to bypass the region lock on a X20 ultra plus?
As for me, I have the exact same problem with my dreame.vacuum.mc1808
as . Is there literally no way to make the map live for this robot, only a static map is possible?
Have this issue with viomi.vacuum.v8
. I am using account with shared home
Hello! is there any way to ask to update the map?
I made the installation of the latest dreame HCAS beta plugin after configuring the robot for the first time. it recognized it and I could see its status, etc. Then I asked the robot to do its initial mapping function. this is what HA shows me as map (entity camera.dreamebot_l20_ultra_map
) and hasn't updated ever since, this was fetched while that initial map scanning was still ongoing.
If I open the device integration page, I can see there is camera.dreamebot_l20_ultra_map_1
entity with a different map which is a more complete version (but still not the latest I see on the app)
On the app meanwhile I added separated/merged areas, added, furniture, carpets, etc.
I've already completed a full house clean, but nothing updates on the map. Is there a way to force a map update? all the remaining entities seem to work just fine (e.g. battery level updates in real time, etc)
@paulo-serrao this is the wrong repo for your problem, you should open this issue on https://github.com/Tasshack/dreame-vacuum/issues I have recently noticed a bug that causes map not to refresh after fast mapping and you should restart your HA to make it working again. This will be fixed on the next beta release but you won't be needing it anymore since you have already mapped your house.
https://github.com/Tasshack/dreame-vacuum/releases/tag/v2.0.0b8
Just for clarification, by installing the beta you should be able to bypass the region lock on a X20 ultra plus?
X20 Ultra Plus is region locked from firmware and it cannot be bypassed with the integration.
@PiotrMachowski I've tried to read the whole thread but still didn't get it - is there any solution for map updates for dream vacuums (I have l10s pro or dreame.vacuum.r2228o)?
The map from this integration updates from time to time. Can't understand why at all. While from this one https://github.com/Tasshack/dreame-vacuum works in real time.
Hi @Nafania
There's no built in solution as of now.
The fix is to create an automation that does the refresh for you when the Vacuum is running. It's not elegant, but it works.
Here's mine, you'll have to update the Vacuum Entity ID/Name.
@Nafania @auanasgheps why don't you just use dreame_vacuum since map card already has support for it. Even you make the map update using the service call, this integration does not render the current map but instead it shows you the saved map with cleaning path applied so it won't look like the same with your app.
@Nafania @auanasgheps why don't you just use dreame_vacuum since map card already has support for it. Even you make the map update using the service call, this integration does not render the current map but instead it shows you the saved map with cleaning path applied so it won't look like the same with your app.
i use it and it's great! thanks a lot for doing it! but I have two different purposes - 1) is general vacuum cleaner control and usage which is done by your integration 2) I would like to have vacuum map rendered on top of my 3d floor plan and this can't be achieved with your integration
- I would like to have vacuum map rendered on top of my 3d floor plan and this can't be achieved with your integration
Maybe I can add something to the configuration settings for this purpose if I know the requirement for it.
- I would like to have vacuum map rendered on top of my 3d floor plan and this can't be achieved with your integration
Maybe I can add something to the configuration settings for this purpose if I know the requirement for it.
- What do you need extactly from map to be rendered on top of 3d-floor plan?
- Can you share the image outputs from both Map Extractor and Dreame Vacuum?
1) I need to have the ability to change colors to put them on top of a 3d-floor plan without overlapping 2) Sure here it is from the map extractor
and here is from dream vacuum
and here is what I want to achieve - vacuum position, cleaning paths on top of my floor map
@Nafania got it, so you basically need transparent map and I have added that feature to the Beta version but the problem with is that it uses the current camera entities as transparent map so you will loose the normal colored map if you enable that configuration option.
There is a fork for what you exactly need that I have helped build for exact same purpose with your setup. This fork of the integration will create transparent versions for each map for use in floor plan but I haven't tested it myself. tungmeister
The reason that I have not implemented this way is the memory requirement of each map but I am currently building a custom card for the integration that will has ability to render only path/vacuum and will be placeable inside the picture elements card.
Description
The current implementation for Dreame vacuums is not able to refresh the map on its own, but relies on the mobile app to do so.
This is the detailed behaviour.
Unfortunately it means we are still heavily dependent by the mobile app.
I have grabbed the Mobile app's log to see what commands are send to the vacuum. I see a lot of calls regarding "get_properties" and these are MioT commands.
I can share the logs privately with you if you provide an email address.
Solution
When vacuum operations are started, implement a logic similar to the one in the app, so we can get the map refreshed independently.
Alternatives
No response
Context
Other non-Dreame vacuums are able to refresh the map without relying on the app.