I just started to learn about developing apps, and as a first project I want to contribute to an already existing app on GitHub. Therefore I forked the project and added a new driver to that app.
Before creating a pull request, I now want to locally test my changes in my Homey Pro, but I cannot run the app with homey app run, because I already have the “real” app installed on my Homey. The validation complains about duplicated flow card IDs, what is totally correct.
Is there a best practice on testing apps in parallel to the stable version already installed?
That validation is based on the code and is not related to having the app already installed on Homey. When you run an app from the CLI it will overwrite the existing installed app.
So the sequence is to compile the app.json file from the compose files, verify the contents of the new app.json and if all is good then write the app to Homey.
So, it sounds like you have created new flows that have the same IDs as flows that are already in the code.
Thanks for that information, I will try to have a more detailed look at the definitions of the new flows. Possibly I did something wrong here.
In that case, should I just change the ID and name of my fork so it can exist in parallel to the original app? Or will the original app be restored after my homey app run is finished?
You can either change the information as you described and have both, provided they don’t conflict in any way (two connections to a server for example).
If you just run without changing the ID then your version will overwrite the installed version, therefore, when you finish you will need to use homey app install so that your version remains running. You can also reinstall the version from the store and it will carry on as it was before your version, provided your version hasn’t made changes to the original devices.
It would be great if you could take over the support for the app completely, because the actual developer Timo is not available since almost a year. I had also written to him personally several times, but there was never a response back.
What I don’t know though, if that would be legally feasible without further action. As far as I know, the developer must at least agree.
1 check the license
2 ask Athom. If the developer agrees he can initiate it from theb dev dashbord or if he doesn’t respond it will possibly allowed by Athom
Yes, I saw that and that was the reason why I started trying to add a missing driver on my own. Maybe it’s a little bit too early for taking over something as I just received my Homey two weeks ago and started to learn about developing for it yesterday
But as soon as I manage to get this running locally I will be glad to help also on other integrations or bringing new things into the official app.
In the meantime I manage to get my development version run on my Homey locally. It worked like explained by @Adrian_Rockall, so I will mark his reply as solution for my thread here.
I just changed the ID and name of my fork, then I was able to run it in parallel to the original app. I had to deactivate the original one because possibly they cannot share the connection to the CCU, but activating again was no problem after my test version was uninstalled.
Regarding the mentioned validation errors I got initally: It seams they were caused by already existing code in the app, in fact there were flows with the same IDs in other devices. Additionally there were some devices with the alarm_battery capability but without the energy.batteries entry in the driver.compose.json. I don’t know why this is no problem in the original published app, maybe the validation is configurable or was added recently?
Anyway, I will create an issue for that in the original repo and provide a pull request for that also.
Thanks for all your help, maybe I will create new threads soon when making progress with my learning on how to develop for Homey
