WIP: Refactoring

[agross]

Hello,

I was thinking about sending an e-mail, but let's try this in public. During the last days, I was trying to get iobroker.lovelace to detect my HmIP-BBL shutters. This didn't work because of reasons found in the Lovelace adapter, but also because of this one here. First I needed to understand that this lib is used to make Lovelace understand ioBroker's states.

My next question was how ioBroker's states should look like in order to be found/understood by Lovelace. For that, you have the Types variable, which is kind-of readable. But it also has some quirks, IMHO. Like having "one-of" arrays for states that make stuff required despite the array elements not being required: true. As someone who doesn't maintain the type detector, this is rather hard to understand.

But the main reason for this PR is that it is virtually not possible to determine why ioBroker states do not end up being detected as blinds/shutters, media players, etc. At least these were the examples I tried: create some channel/state structure inside alias.0 and see if Lovelace displays new entities to add to the UI. I failed at both shutters and media players.

To understand what was going on I added lots of logging to ioBroker.lovelace. I found that it didn't receive blinds or media player controls from this library, so I dug here. Please understand that as someone who didn't write this code it is a bit hard to understand. It's not well documented. There are almost no tests. For the media player alias structure, I was able to write a unit test that succeeded. But when I replicated a similar structure in ioBroker there was again no media player control passed to Lovelace.

My main points are:

• As someone that has written code before but didn't maintain this project, the code is hard to understand
• There is absolutely no way to log the things iobroker.type-detector does in production, most importantly why it won't accept states as some type
• I believe there are lots of low-hanging fruits w.r.t. refactoring. If you follow my commit log you see that by extracting functions and inverting ifs the code can be flattened and made much more readable.
• I do not know the ins and outs of this adapter, so I will likely ask for help

This is why I started changing the code structure (i.e. not the semantics, hopefully) and opened this PR. It's not finished yet, but before I invest a lot of time I wanted to ask whether you are even interested in it. I believe the code that is the foundation for Lovelace and other adapters should be written in such a way that adapter authors can understand how it works and how the states are supposed to look like without much head-scratching.

Please let me know what you think. Thank you for listening.

Alex

[GermanBluefox]

Thank you for your PR. And sorry for delay. I still need some time to check your PR.

[GermanBluefox]

I have done the merge, but it was not possible to merge automatically. I like your refactoring and would appreciate future optimizations. :)