Addon version

[anthony2856]

Hello,

I just made an addon implementation of your project. I think it's a better way to use the project than putting build folder directly in www folder. Easier for "lambda" user and easy to maintain up to date.

Here is the repo of the addon: https://github.com/anthony2856/hassio-tileboard-addon

Let's have a look on it and tell me what you think ;)

[rchl]

How would the experience of editing the configuration file look like with that?

This project doesn't have any way to configure the settings using a UI so the user needs direct access to configuration file somehow.

[anthony2856]

The only configuration you have to do with this addon is to set the path to your config folder (located in /www).

Imagine you set configFolder: "tileboard", then you'll have to create the folder <config>/www/tileboard (restart HA if www folder did not exists) and put your config(s) file(s) inside. You could also put an images folder. Everythings in this folder will be copied to the directory of the application. For now, if you change something in your config file, you have to restart the addon to take into account any changes. I'm thinking about making a symbolic link between config folder and the app to not have to restart the addon but i don't have tried yet, missing times...

For now, the addon is based on the latest release 2.0.3, but it could be great if a release of your project could make a release of the addon. This way, users will be automatically warned that there is a new release and could update app from Home Assistant :)

I'm planning to create a "builder" for this project, i really like it, you've made a great job ! The idea of the builder is just having some typescript interfaces to help user to create config file and use rollup to transpile and set everything in a config.js file, what do you think ?

[anthony2856]

I've just commit an update to use symbolic link instead of copying files. So now, you just have to reload page if you made changes to your config file. But if you add a new file, you'll have to restart the addon.

[rchl]

I think it would be great to have an addon like that that would auto-update instead of users having to handle that themselves.

Also, if this solution doesn't compromise on anything that is currently possible, then I'd be open to making it "official" and handling it entirely within this repo.

I'd just need to find some time to play with it and understand exactly how it works first.

I'm planning to create a "builder" for this project, i really like it, you've made a great job ! The idea of the builder is just having some typescript interfaces to help user to create config file and use rollup to transpile and set everything in a config.js file, what do you think ?

That part sounds interesting but I don't fully understand how do you envision it working. Would the idea be only to use it to kick-start a config file? And from there the user would update it manually? I'm asking because I think that it would be rather hard to make it handle complex cases that require manual editing of the config.

[anthony2856]

Yes, for sure ! I also think the addon has to be in this repo to be auto upadted with the new release ;) My idea was first to make a POC and see what was possible to do ;) So, feel free to take my code and use it like you want ;)

For the builder part, the idea is just to provide typescript interface to the user so he can have auto completion when he is creating his config file. The best solution would be if the application was made with Typescript. This way, the build of the application would publish a npm package with interfaces corresponding to the app. Do you better understand what i'm thinking ?

[rchl]

Types can be created manually and included in the project, together with appropriate tsconfig.json configuration. I was meaning to do that anyway.

[anthony2856]

Yes, it is possible to do that manually but it implies do synchronize interfaces manually with the app, it can be time looser, no ?

[anthony2856]

For the addon part, would you like me to make a pull request for an implementation on this repo ?

[rchl]

Sure, go ahead. :)

[anthony2856]

Hello @rchl , I'm working on the PR for the addon implementation. I have a constraint and i want your opinion on the best (prefered) solution. The problem is, to be detected by Home Assistant, the addon need a config.json file with a correct tag version. You will understand that is a duplicate with package.json version field. So i was thinking of update onPush github actions to retrieve package.json version and put it in the config.json file, then commit the config.json file. This way you don't have to manually handle this file. But if I do this, you'll have to first push to master, let the github actions run and create the tag on the recently created commit. The other way to do this is to manually changing version field in config.json..

Not sure i'm really understandble, sorry for my english... :/

[resoai]

I'm sorry for being slight off-topic here, but perhaps we could use this opportunity and use ingress for the add-on? This way we no-longer have to worry about tokens being exposed and other authentication issues?

[anthony2856]

Hi @resoai ,

Will it be still possible to have TileBoard in a proper tab on your browser or will it be fully integrated into Home Assistant ?

[rchl]

to be detected by Home Assistant, the addon need a config.json file

I assume you are talking about a different config.json than the one that is used for TileBoard configuration?

If that file will live in the repo then the version could be adjusted on releasing which happens manually with yarn release. I think it should be possible to hook into that and do the required modifications. Doing it from CI is a bit "late".

I'm sorry for being slight off-topic here, but perhaps we could use this opportunity and use ingress for the add-on? This way we no-longer have to worry about tokens being exposed and other authentication issues?

As @anthony2856 mentioned, I think it would lose the ability to be loaded separately and be installed as a web app.

[resoai]

I think we would still be able to load it in a separate tab just fine, if I understand correctly but definitely need to investigate it.

[anthony2856]

I assume you are talking about a different config.json than the one that is used for TileBoard configuration?

Yes it's a config.json used by home assistant to detect version change, which docker image to use, etc. Different from TileBoard one ;)

If that file will live in the repo then the version could be adjusted on releasing which happens manually with yarn release. I think it should be possible to hook into that and do the required modifications. Doing it from CI is a bit "late".

I will have a look on what is done with yarn release, you're right it's a bit late doing it from CI.

I think we would still be able to load it in a separate tab just fine, if I understand correctly but definitely need to investigate it.

If it still possible to open it in a separated tab, no problem with that. I just don't know how it works for now but i will have a look on it ;)

[rchl]

I will have a look on what is done with yarn release, you're right it's a bit late doing it from CI.

The standard-version package that is used for releasing supports various hooks (some are even already used): https://github.com/conventional-changelog/standard-version#lifecycle-scripts

[anthony2856]

Nice package, i did'nt know it. For the version number in config.json file it will be pretty easy i think. But I also have to copy README.md + CHANGELOG.md to the addon folder (again to be used in addon description in home assistant)

[rchl]

I think we would still be able to load it in a separate tab just fine, if I understand correctly but definitely need to investigate it.

I don't have any experience creating ingress addons but from my experience using them, you can either open them from the panel which gives you the benefit of auto-login or you can open them using the ports they expose but then you don't get benefits like that.

For example, NodeRed addon will auto-login if you open it from the sidebar but if you go to :1880 then you have to login manually.

[rchl]

But I also have to copy README.md + CHANGELOG.md to the addon folder (again to be used in addon description in home assistant)

You can even just use shell for that (cp src dst). That won't work on Windows but that's probably OK. There are also cross-platform alternatives of course.

[anthony2856]

Ok it works like a charm 👍 I used bumpFiles option to set version in addon/config.json and i used the postchangelog hook to copy README.md and CHANGELOG.md to the addon directory ;)

I will have a look on ingress capabilities tomorrow

[anthony2856]

Hi, I've just look the NodeRed plugin but it also expose an nginx server but use ingress for the home assistant side bar. From what i understood.

So, for me I don't see any benefits to use ingress for this. Could you explain your needs @resoai ?

[rchl]

I think the benefit could be that the user wouldn't have to login manually.

[anthony2856]

But only if the user is using the addon inside home assistant right ? For me the big advantage of this project is to be used on wall panel right ?

[rchl]

But only if the user is using the addon inside home assistant right ?

That's the part we are not sure about and wanted to be checked. But I believe so, myself.

For me the big advantage of this project is to be used on wall panel right ?

You can still do that with ingress, I guess. Only that the user would still have access to the rest of the HA by clicking the "hamburger" menu.

[anthony2856]

You can still do that with ingress, I guess. Only that the user would still have access to the rest of the HA by clicking the "hamburger" menu.

Yes, it's personnal, but i think it will be better not seeing this hamburger menu. And let not the user go away from the panel