dennisschroeder / khome Goto Github PK

I'm interested in using Khome in a mobile app that runs on both iOS and Android using Kotlin Multiplatform. Would the collaborators (y'all) be interested in making this project multiplatform compatible? Notably this would mean swapping any incompatible dependencies with compatible versions, like KotlinLogging -> Kermit and Gson -> kotlinx.serialization. I'm happy to help with the work, but can also easily maintain a fork if this isn't something wanted in the main repo.

Additionally, if there are any changes to make Khome usable as a library in a mobile app then I'd want to make those changes as well (in case that affects the fork vs. no-fork decision).

Very cool project, and thanks!

First of all, I'd like to say thank you and well done!
I'm a great Kotlin fan myself and while I was using AppDaemon for my automations, all this loosely typed nonsense is driving me nuts. I'm very interested to be able to automate parts of my home using a proper programming language like Kotlin.
I am wondering however how you're currently running khome to test it. I understand it can be run from any device that can run Java, so running it from hass.io shouldn't be a problem. However, hass.io does however require an add-on (because of docker and such) to be able to run it, turn it on/off and update it eventually (like AppDaemon).
So that's my humble request for now, other than that, keep up the terrific work :D

Edit: I am a bit curious why it is necessary to create all these classes for simple actions like turning on a certain light. I mean, shouldn't

callService(TurnOn(Light("wall_lamp")))
// Or even
Light("wall_lamp").turnOn()

be a lot easier and lower the learning curve from the python people we're trying to convince to switch?
I assume it's necessary for that Koin stuff, but it does increase the difficulty of using it a lot I think.
Anyways I'll have to play with it to be sure of course.

Edit2: After playing around a bit, I do think that using Koin to make the code more DSL like is hurting the actual usability of the library. To turn off, say 10 light, instead of just creating Light objects from a list of entities and turning those off with a single forloop, now I'd have to create a class for any light in the house, plus for each light a TurnOffLight and TurnOnLight class, I'd have to register them all as beans and then I'd have to callService<>() manually for each light!
Plus, when I add a new light, I'd have to do it all again!
I think some things of your library are great and the amount of work you've put into it is clear, but I think it wouldn't hurt to pursue a simpler approach, like AppDaemon. Abstract away from the service calls and make entities instances. At least that's how I would do it.