I have read there was something in the past but it is removed and not returned.
So therefore this suggestion to create a list with all supported apps and devices (if possible including the github apps), categorized by type and also including how Homey is able to use it. So which events, variables and actions can be used/triggered via Homey? In other words, how can the app be used in flows in the IF, AND/OR and THEN sections.
It would be great to get full potential of what you have, but also to be a factor in which device to buy if there are multiple choices and to see if you miss something without knowing.
Good suggestion. As this is something Athom would never do and has to be done by a volunteer, are u volunteering for it? It’s gonna be an endless list which keeps growing by the week me guess. Not doable at all.
However if you want to know if a specific device is supported, choose add device in the Homey app and use the search field. It’ll give you specific devices instead of apps.
Very good idea. I’ve sent recently an idea for a wiki or a sub forum for every app to describe how it works and what you actually can do with the flow cards.
Some apps don’t have a lot of “readme”. So a good manual, some (good links to) tutorials and a neat description of all the cards. And some example flows to get the most out of it.
True that it would be a gigantic job to do it. But that search option you mention is just not doing it. If I would like to add a Weather station, it will show all apps and devices with weather in the name. So also weather apps. And it does not show all the opportunities. It depends on what the publisher of the app/device has decided to share. Some descriptions are very short and just rarely it shows which events/variables/actions can be used. So that does not solve the issue I am addressing.
An example of a pretty good description is Foscam app by Edwin van de Pol I found yesterday doing looking for supported camera’s the hard way (manual search through the library). It tells what it supports (and what not), which actions are supported and which triggers. I do not see anything on variables which can be read in there, but I do not know if there are any. But that is a pretty good example to act as a “template”. But this is so rare.
Lots of apps used to have more “readme”, but Athom decided that lots of text (with proper formatting) isn’t what users want to read. Instead, an apps’ description is now literally meant to “sell your app”.
Exactly Renzo! That is what I am addressing. Like my other post, the Foscam is app is a pretty descent description but it is so rare.
I also had the idea of a wiki which can be maintained by all of us. That would be great. And per device/app using a template for information (description, supported devices and not supported, events, variables, actions and indeed maybe some examples). If there are enough people wanting to maintain it, the gigantic job it is will be spread over many people doing a small part sharing knowledge. In my opinion that is the important thing of a good wiki.
But I have no experience in setting up a wiki. I have no idea how much time that will take.
And I do not know if it needs a kind like an admin (group) who needs to check if there is no rubbish and that all entries are in a kind of template, etc. And how much time that will take.
And whatever things I do not know off at this moment that will take time.
@robertklep
In the app directory that is completely logic. Some apps do have a tutiorial there, which looks complicated.
But on this forum or a wiki somewhere you could help users a lot with in depth readme’s, tutorials and sample flows.
Sample flows are in general a good way to discover possibilities and new ways to combine apps in flows.
If you ask me, Homey isn’t really actie on this part. Which’s could also gain more customers because you make its simpler for a lot of people.
@Johan_Bakkers
Setting up a wiki isn’t hard, but we need space. And time. Well. I’m still learning. So it’s not really a time consuming thing to just add some of what I’ve found in a wiki.
We could use a GitHub wiki, as I was looking over there. Each app, one page, in different ‘chapters’
