Firmware customization via Konnected app for Homeseer

Nate,
I finally got around to building a FW using the app and uploaded it to Alarm Panel Pro.
At the moment, The Konnected App finds the device and can display the web interface, but Alex’s plugin no longer finds the device - something I’ll ask him about on the Homeseer forum.
BUT - I wondered about WiFi vs. Ethernet. The old FW update process asked which you wanted? This process never asks, either when configuring the FW Options or when uploading. So, does the FW now automatically detect internet connection? Does it prioritize hardwired?

Here is how I set the Settings - should this be correct for HomeSeer?
Name: Alarm Panel
Zone Settings: I enabled all 12 zones and set them each to a custom name and set the type.
Enable Konnected Cloud: Disabled
Local Native API: Disabled
Local Web Page / API: ENABLED

The App and the build and upload process is very elegant by the way. Now to just get it to work with Homeseer :slight_smile:

Nate,

OK, I’ve been experimenting and “Houston, we have a problem.”
If the native API is not enabled, the Alarm Panel Pro DOES NOT show up on mDNS. And so Alex’s plugin won’t find and configure it. It can be manually installed using the IP address but this is a) not user friendly and b) has some side effects, like Homeseer doesn’t pick up the device name, doesn’t configure icon’s correctly, etc.

We need an option that:

  1. shows up on mDNS scans
  2. does not reboot every 5 minutes if it doesn’t find Home Assistant.

Or - is there a way for Alex to fake it and make Homeseer look like a HomeAssistant client is connected?

Nate,
Any thoughts on this since you split it into it’s own thread?

Yes, I will address this. I see what the problem is, and I think I have a good solution. I have a few other things to wrap up ahead of this but will circle back on it soon.

@BuddyRayAtl @alexbk66 I addressed this in a recent firmware update. See release 2024.3.2 notes here.

Basically I’ve added a _konnected mDNS service advertisement that is always present, even if the ESPHome API is disabled. I didn’t realize that disabling the native API would also nuke the mDNS detail.

You can update firmware by rebuilding a new version in the Konnected app, or starting over from scratch by installing the base firmware via https://install.konnected.io

Nate,
That should be perfect.
However, I’m in Texas visiting family for Easter and will stay through the eclipse. Be home around 4/18. I’ll test then. I just didn’t want you to think I was ghosting you :wink:.
Just living my best retired life.

No rush on my side. Enjoy the break.
I think @alexbk66 will have to update the Homeseer driver to scan for the new service name before it’ll work in Homeseer. I’ve tested the mDNS broadcast of course and it’s working fine.



OK, I’m back from travels and working with the Alarm Panel Pro, the new V4 firmware and AKKonnected plugin on Homeseer.
I’m honestly not sure if this is Konnected or AK’s problem so I’m posting all this on both forums.

I used the app to generate a new firmware V4 with settings in the attached screen shot: Konnected Cloud Disabled, Local Native API Disabled, Web page/api Enabled.
The over the wire update fails (see screen shot) so I flashed it using USB. Successful.
(as an aside, after getting V4 flashed, I tried the over the wire update again, it still failed.)
Enabled the latest AKKonnected plugin in Homeseer. It errors out, can’t find connections.
I verified the device web page is active and working.
I captured attached log.
I tried to capture a Konnected log (attached) but it’s basially blank except for one message.
I fired up zeroconfServiceBrowser and it doesn’t seem to find the Alarm Panel (It finds the GDO fine).
I’ve attached screen shots I thought might be relevant to debugging.

Nate - did I set the firmware build right? I think I set them per your last post but if so, the device isn’t advertsing itself under just the Local WebPage/API enabled.





On another minor note. In the app, when I set the Network to WiFi the app hung. See the attached screenshot. It opened a box (at least I think it was a box in the upper left corner but it didn’t have borders. It let me set WiFi, but then I couldn’t get rid of the box. The ← didn’t work. I had to close the app and start over. It does that every time. Luckily, I have one of the boards with the bad Ethernet anyway and it was already defaulting to WiFi. I just thought you would want to take a look at the data entry on that screen.

Hi Buddy,

At what point is the OTA (over the air) firmware update failing? Does the progress bar move at all, or is failing at the start? If your device isn’t showing up on mDNS/ZeroConfService scan, that could indicate the Alarm Panel isn’t on the same WiFi network as your phone and could be why it’s failing.

Thanks for the heads up on the Network setting causing the app to hang. I’ll look in to that and get a fix out for it. We will have an update out soon that will help us debug and find the source of these OTA update failures as well.

Connor,
The OTA seems to try for a minute before the failure box pops up, but you’re right, I don’t think it’s ever finding the device because it never starts a progress bar.
I’m a retired network and software engineer. I’ve built networks for News Corporation, AirTran Airlines and other major corporations. Trust me, I only have ONE subnet and during testing, both devices are even on the same access point. Plus - the mDNS works if the Local Native API is enabled. But if you follow the history of this tread, you guys were changing the configuration where mDNS was advertised even if Local Native API was disabled. I doesn’t look like that change worked. Just guessing.

My two GDO BlaQ’s came in this afternoon and I started to configure them.
Guess what - same problems configuring for HomeSeer as those in this Tread.
Related Thread

If mDNS is enabled on the GDO BlaQ and the AlarmPanelPro, can you verify what the Service, Protocol and Port is?
see: https://esphome.io/components/mdns.html

@nate I’ll update my FW and see how it goes.

In my HS driver I can have multiple mDNS services, i.e. currently _http._tcp and _esphomelib._tcp, so I can add another one and keep old ones too.

Ok, installed latest FW on GDO White (old) - now it does show mDNS “_konnected”, the only small issue (see next post as I’m unable to insert two images in one post):

@BuddyRayAtl @alexbk66 As of release 2024.4.2 all of our products firmware should be advertising a _konnected service to identify the device. The default HTTP port is port 80 (but this can be customized). The _konnected service will always be advertised even if the ESPHome Native API is disabled.

Out-of-the-box all of the products (including the new GDO blaQ) will have the Native API and Web API enabled and will advertise both the _konnected service and _esphomelib service. The _esphomelib advertisement will go away if Native API is disabled.

@buddy in the zeroconfServiceBrowser window you posted above the project_version is 0.0.1 which is too old to have the new _konnected service which was added in version 0.2.0 of garage-door-gdov2-q

I’m a little confused why the OTA update isn’t working for you. We’ve had a few other reports of this and we’re working on an app update that adds some additional logging and error messages so we can figure out where it’s breaking down. OTA update seems to be working for most people (and is working great for me) so @Connor_Martin is adding some telemetry to help us pin down the problem. @BuddyRayAtl are you iOS? I would be happy to include you in the TestFlight app builds so we can quickly get confirmation of updates.

@nate if you read my above post?

The mDNS works, but the WebServer doesn’t!

Ok, after two FW updates via the APP it now seems to work - both mDNS and the WebServer.

@nate I must admit - it’s very frustrating experience getting this to work. Even for tech minded users like myself.

You really should simplify and streamline the setup process - it takes a lot of trial-and-error to get it working. It shouldn’t be so difficult.

image

@alexbk66 glad you got it working. Not sure exactly what the problem was. The web server works. It’s provided by default by ESPHome. The screenshot that you posted does not provide any useful information as to why the site was unreachable.

One guess – the ESP8266 chips (which are powering the GDOv1) require a power-cycle or hard reboot after OTA update. I’m not sure why this is, just a limitation of the chip I guess.

You are right it shouldn’t be difficult. Most users have no problem. ESPHome is open-source software, and we’ve put in a lot of energy into creating the tooling and process for end-users to be able to use this software without knowing anything about the software. It’s not perfect yet but we’re improving the products and the process every day.

All of our firmware configurations are open source, so if you have an idea to improve something, please you are welcome to contribute!