Feature request: Add device prefix to related entities upon installation

[MaxVonEvil]

After re-installing v0.4.4 due to the Unknown User error, the entities obvously reverted to their default names. I had previously renamed them to avoid potential name collision with other devices and to help group them in the entities view. Per default they get created as such

While one could of course rename all 20-something entities post-installation, it's still possible that reinstalls could be warranted further down the road, thus I would like to suggest the ability to add a custom prefix_ at installation time, so the above entities would look something like this:

binary_sensor.poolbot_awsbroker sensor.poolbot_cleanmode sensor.poolbot_cyclecount sensor.poolbot_cycletime ...etc

Let me know if this makes sense, thank you!

[elad-bar]

Integration takes it from the robot name, did you set it in the mobile app?

[MaxVonEvil]

Correct, said prefixes are not in the mobile app / API on most entities, which I guess kinda makes sense, as MyDolphin isn't aware of HA.

That said, it would make life easier on the HomeAssistant side if your integration would offer the option to add a custom entity prefix upon installation.

As you can see below I've just completed renaming the entities back so they match up with existing HA dashboards and automation, which I've built around the poolbot_ entries.

[elad-bar]

The integration is taking it from the robot name, why do you need to rename it? I can work on it so it will take it from the integration title so you will be able to rename it, by default it will be the robot name, would it work for you?

[MaxVonEvil]

So the reason I need to rename is that there are other integrations which have colliding entity names, so you end up with _2 suffixed entities and it can be challenging to discern when you are referencing them in automations, which one is what.

I suppose the robot name is fine, as it presumably would be unique and there's less UX items you need to add to the code.

Thanks for your flexibility on this. If you are interested, I have some other ideas which you may wish to consider to improve this massively useful integration.

[elad-bar]

I just relaized that something is wrong if that's what you got for entity names, can you please share with me the diagnostic file of your integration? please remove / or mask from it the follow parameters:

• data.api.aws-token-encrypted-key
• data.api.serial_number
• data.api.login_token
• data.api.motor_unit_serial
• data.api.Token
• data.api.AccessKeyId
• data.api.SecretAccessKey
• data.api.Motor Unit Serial

thanks

[elad-bar]

seems that there is an issue with latest version, your diagnostic file will assist to confirm, when using the shared device, it sets the device name as empty, which causes no prefix, as workaround up until new version with fix for it will be available, you can manually change the device name and when HA asked you whether to update all entities, need to click on Rename button.

[MaxVonEvil]

Sounds about right, that would explain the non-prefix. So, do you still need the diagnostic file? If so, I'll be happy to plop the robot in tomorrow afternoon when I'm done with work, but let me know if it's still relevant

On Mon, Jul 10, 2023 at 12:25 AM Elad Bar @.***> wrote:

seems that there is an issue with latest version, your diagnostic file will assist to confirm, when using the shared device, it sets the device name as empty, which causes no prefix, as workaround up until new version with fix for it will be available, you can manually change the device name and when HA asked you whether to update all entities, need to click on Rename button.

— Reply to this email directly, view it on GitHub https://github.com/sh00t2kill/dolphin-robot/issues/124#issuecomment-1628388216, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEXRQVGXCT2KCD4EF446DODXPOU6TANCNFSM6AAAAAA2DTW6QE . You are receiving this because you authored the thread.Message ID: @.***>

--

With best regards, Max Ranzau / +1 610 462 2200

[elad-bar]

you will have it by tomorrow, just need to test the version, but to confirm that the problem is like that, I need to see the diagnostic file, if you can share it.

[elad-bar]

please check new release v.0.4.6, managed to reproduce the issue, with that version it worked as in the past, extracting the name of the robot into device name so all entities will have that prefix

[MaxVonEvil]

Hi, sorry to report that v0.4.6 is not doing any better, i.e. still producing the entities without any prefix. This is what I get:

As you can see, the only entity which reads the unique name (hXXXXXXX) is the vacuum entity, however it unfortunatly gets created with a blank entity name as you can see. The rest of the entitities do not get the prefix.

Question: Are you planning on using the full unique name (mydolphin_plus_vacuum_hXXXXX) as a prefix on the resulting entities? If that's the case, I would really like to advocate for the option to put in something shorter.

Re. debug - perhaps I'm going about it all wrong, yet I am having problems generating you a debug log: Problem is that when I install the integration, I won't be able to turn on debugging in time as the integration isn't installed yet. If you can offer any advice on turning the debug on or in what sequence you'd like it done, I'll be happy to do it.

[elad-bar]

You can set the debug log level within the yaml configuration of HA, instructions available in readme.

As for the full name, no mostly because i'm relaying on the device name, but you can change the device name as you wish.

Just to be sure, you have installed new version, restarted ha, removed previous integration and only then added new one, right?

In addition, to investigate it i must see both logs and diagnostic file with the cleanup as suggested above (unless you would like to share it privately to me in discord)

[sh00t2kill]

@MaxVonEvil i think we are looking at the wrong issue here.

The issue is your vacuum entity being empty. It should NOT be. Have you named your cleaner in the my dolphin app?

Eg, mine is called Jose (dont ask)

All my entities are prefixed with Jose.

[elad-bar]

yes, that's why I would like to get the diagnostic file - in the api section we can find the robot name as written within the mobile app, from there it will take it to the device section, the name there should be as the robot name from the api or manually changed to a different one, as result of that entities will have the same prefix, if you set the robot name to empty, you will not have a name, which could lead to the problem, another issue which was solved yesterday with additional release as written above, is that in some cases when the creation of the entities happened before getting the robot name it led to situation where the device name is empty, but it was fixed and now in order to create entities, the integration waits for event that the robot name was received by the API.

if the latest version didn't solve it, I will need diagnostic file and logs to understand how it happened.

[MaxVonEvil]

Ah, that's where the problem was. While I initially did set up the robot name, (no judgement ;-) I did at some point reset the app per Maytronic's support instructions. Interestingly enough, the mobile app never prompted me to set up the name again, so when I checked it yesterday, the name was indeed blank. I'll get you a diagnostic readout later as I test this.

[elad-bar]

No need, now I know that the robot name can be empty, so I just need to give it default name, I'm thinking of My Dolphin {model or SN}, wdyt?

[MaxVonEvil]

Ok, thanks - As for naming MyDolphin (no spaces) is probably fine. As for sn/model, it would probably only be applicable if one has multiple units, which might be an edge case anyhow. If you want to ensure uniqueness, to keep it short, perhaps just add an integer after the name prefix such as mydolphin1, mydolphin2.. Just my $0.02

Btw, this is what my PoolBot dashboard looks like:

[sh00t2kill]

@MaxVonEvil FWIW you can't actually add multiple robots to the same account. It's a silly limitation of the my dolphin platform. It's dumb.

That's one of the reasons this came about, facilitating control of multiple robots.

[MaxVonEvil]

Heh, who would have thought. Anyway, in that case then I'd suggest just to keep a simple MyDolphin prefix, in case no name is defined.

[elad-bar]

pls check the new release v0.4.7, default name is MyDolphin Plus, i encountered the same issue as my app disconnected from the robot and it most probably forgot its name

[MaxVonEvil]

So I just upgraded to v1.0 which came out 8 hours prior to time of writing. While the integration still seems to work, during the upgrade it created new double entities for some of the entities and ignored the old ones.

Specifically this happened for all the schedule related entities and the AWS broker entity, all other entities seem unaffected.

Result looks like this:

Old unavailable entity example:

Corresponding newly created entity. Note that the integration tries to create it with the same name as the old one, hence it gets a _2 suffix:

I'm going to clean out the dead entities, remove and reinstall the integration, then hopefully things get cleaned up.

[MaxVonEvil]

(on a a partially related sidebar, I really don't get why Maytronics have all that scheduling stuff in the app anyway. A couple of months ago I was overseas for 3 weeks, prior to travel I asked their support if it was okay to leave the robot in the water for 3 weeks and they very much recommended NOT to do that.

So not really much point I suppose. Dunno about the rest of you, I just pop it into the pool every week, let it do it's thing and haul it out again)

[elad-bar]

(on a a partially related sidebar, I really don't get why Maytronics have all that scheduling stuff in the app anyway. A couple of months ago I was overseas for 3 weeks, prior to travel I asked their support if it was okay to leave the robot in the water for 3 weeks and they very much recommended NOT to do that.

So not really much point I suppose. Dunno about the rest of you, I just pop it into the pool every week, let it do it's thing and haul it out again)

Yes, it is not recommended as chemicals are damaging the unit, schedules seems like an half backed solution

[MaxVonEvil]

Btw, while we're at it - do you have any insight into the manual drive mode?

When you do it from their app it's slooow to react. Like if you turn the unit, you have to release the steering control about 2 seconds in advance or it will overshoot the direction you're aiming for.

I shared my gripe with Maytronics support and they gave me some fairy-tale how the signal has to travel from the app to the controller and down the wire to the robot. I call BS on that as my typical lag on my network from sensors to actuators (like PIR to a light) is about 25ms. There is absolutely no reason why local comms should be 100x slower

My guess is that every turn/move command from their app has to go up via their AWS instance, which by gauging it's reaction time, they are running it on a virtual Commodore 64...

My question is, has anybody tried to reverse engineer the comms between the main unit and their cloud, or better yet maybe rip out that ant brain in the controller, replace it with something completely on-premise, like an Pi, ESP etc. Thinking of the OpenMower project as inspiration for eventually cutting yet another unnecessary cloud dependancy.

[elad-bar]

Let's have it discussed in discord, in general, it is supported.

Can we close that issue?

Thanks

[MaxVonEvil]

Yep, no problem.

[MaxVonEvil]

Thanks for the Discord invite, however it's unfortunatly not working

[elad-bar]

https://discord.com/channels/1016529558087938168/1016529558553514006

[sh00t2kill]

https://discord.gg/Y5x538gb