I’m actually a big fan of Ollama for certain tasks, but for this ‘Architect’ role, I’m less worried about where the AI ‘thinks’ and more focused on where the logic “lives”.
Since the AI is only used as a development tool to generate the JSON for the Advanced Flows, I can use the most powerful models available to handle the complex spatial layout and logic. Once the ‘Compile’ is finished and the flow is pushed to my Homey Pro via the API, the AI is completely out of the equation.
OTOH, marking apps as “official” when the brand has nothing to do with it, as with many Homey apps, is equally confusing.
And one of the features people have asked for for many years: give us access to logfiles so we (or the app developer) know why $X is failing. Otherwise, both users and app developers are in the dark when things fail.
Many Github issues that I get for my apps are simply “It doesn’t work”, because that’s just about all that a user can provide. Even if an app outputs a lot of debugging data to stderr/stdout, diagnostics reports are often lacking in relevant information.
And how do you deal with users that are reporting that they get “An unexpected error”?
I hardly ever have to check HA logfiles, or “control the code”. It mainly just works. If it doesn’t, at least I have the opportunity to check a logfile to see if something is being logged (or, if I wasn’t able to understand the logs, at least be able to post a logfile to a Github issue where people that do understand them can help out).
Unless it doesn’t work, and then you have a problem.
With Homey you still have a “dongle jungle” (well, okay, “SoC jungle”), it’s just hidden from sight. Homey can fail as well (look around the forum), and when it does, you won’t at least have the option to potentially fix something yourself other than resorting to “let’s try a reboot”.
I guess I’m lucky with my 150+ HA automations that never break.
Official apps are built in collaboration with the brand. I wanted to publish my apps to Homey Cloud myself for quite some time now but when I check the guidelines, it explicitly states that you need the app needs to be published by the brand and any apps that aren’t will get rejected (even if you pay the €100/year fee). Since all of my apps use reverse engineered APIs, obviously none of them would get approved.
Developers can still view errors in the diagnostic reports (if you log them with this.error)
Mostly I would just ask them for the diagnostics report where it’s all logged in the stderr.
I also have another system for submitting information about (unsupported) devices themselves (a complete info JSON from the vendor’s cloud). This uses the App Settings page where under each device there is a “Send” button which asks for a user’s name and an optional message. It then sends the report to my Vercel function which puts it in a DB and sends me a push notification on my phone.
I also use that same system for anonymized (automatic) reporting of unknown statuses from the vendor’s API, because it makes it easier to reverse engineer APIs for products I don’t own myself. When I’m testing a new app (for which I don’t own the actual device) with someone, I also use the same system to send me all the JSON details, this way I don’t have to build an app settings page and can just send it automatically as soon as the tester adds their device to the app.
There is often very good support, especially from the community developers which means that you can get your issue resolved quickly. But developers don’t always have the time for it, so then you’ll have to wait. For my own apps, I always try to reduce the support requests I get by making everything as stable and as easy to use as possible. This means I generally try to avoid LAN/local communications since then I would just be spending hours solving someone else’s network issues. I always try to use the cloud where possible, since it simply always works, no matter what (advanced) network configuration the user might have.
I understand and agree with you. But the internet involves a lot more components than a LAN, so it is rather strange that a simple LAN is complexer to debug then the Internet. In a LAN a component can be reached or not. So adding a few test for connectivity and clear feed back to the user might solve your problem, and allows the user solve his LAN issues.
One of the issues for example is that when an IP address has changed, it is not possible for the user to manually update the IP-address in the app. Which is a pity.
Yes, I always try to detect IP addresses via the cloud (for example, my ASUSTOR app uses the EZConnect service to discover the LAN IP addresses of the NAS). Since the EZConnect service is always up-to-date on the new IPs, it’s a great way to find IP addresses.
Well, it depends on how you see it. Internet access is generally always available on the Homey (it’s even required to use the web app). It’s almost never restricted. Unlike LAN, which can be very restricted (client isolation, guest network, firewall rules, etc. blocking LAN communication).
And cloud communications also work no matter where the device is. If you have a device in another house, you can still access it from Homey.
