When I installed the FW (not customised) first time I selected the “new” FW, then it wasn’t obvious in the Android app what to do. Basically it showed the device IP address so I click on it, but it said “page not available”.
It’s not clear what to do after I install the new FW. I suspect now that it was showing old IP address, but how do you update the device info in the app?
Then it told me that “FW update is available”, so I had to go through the process of building custom FW, etc. It said again “FW update is available”, so I did the build again, after that the web page was working, but the IP changed.
I’m not sure what the process should be, incl. re-connecting to the WiFi and re-connecting to the app. Currently it feels like trial-and-error.
I’m not complaining or blaming, just sharing my experience. I feel that the app is quite fragile still, i.e. just wanted to check my FW settings - the page was empty. Restarting the app made the settings page appear…
BTW, I have only Local Web Page selected, but all three mDNS entries are still showing:
Like Alex, I have created several firmware builds and they don’t seem to come out as I intended.
I have a theory that I’m going to work on testing this morning. The app comes up by default in the configuration in Alex’s screen shot above - ie.
Konnected Cloud disabled,
Local Native Cloud disabled,
Local Web Page/API enabled.
Since that is the exact configuration I wanted, I didn’t change anything, I just hit “Save” and then “Build” and then when it finished building, Install.
Some interface libraries I have used in the past track if the user has actually changed anything on the screen and only SAVE the screen if something has changed.
Could this be what’s happening? Could the app be using the default FM because it didn’t think I changed anything?
I’m going to change something, Save, change it back, Save, then build.
Standby.
We’re making progress. A few more issues and BlaQ and AKKonnected are going to work great and provide a solution to a lot of people for the Chaimberlain problem!
I confirmed just this morning that the native API is being enabled even when we think it’s disabled. This is because another package is inadvertently activating it.
Thanks Nate - I’ll stop my experiments for now until I hear from you.
Are your servers down today? I started two firmware builds at about 11am and they are both still running as of 1pm, even when I close the app and reopen it. Also no e-mail telling me they are finished.
There doesn’t appear to be any way to cancel or reset the build process.
Nate, you may also have to reset my account or something. I can’t get control of my app back. If I click on a device, then click on settings, I just get Preparing Firmware… and the spinning wheel GIF.
I’ve tried hitting the blue button to refresh the app list. I’ve tried closing the app. I’ve tried uninstalling the app and reinstalling. So I have to assume that when it logs back into the server, the server is reporting that it’s still “Preparing Firmware.”
If it helps its:
GDO blaQ 61290c
GDO blaQ 613200
both of them are hungup.
Probably need to add timeouts or something to this routine.
I’ve aborted these manually, you should be able to restart now.
Sorry for the hiccups. The release of the new blaQ has increased the usage of this build system, and I’m starting to see where the process can break. All in the name of incremental improvement!
OK! I just generated new FW for both my blaQs and it built smoothly, uploaded over the air smoothly. I was very careful to make sure that only Local Web Page / API was enabled.
The app shows that version 1.0.2.3 is installed, which should be correct (the third time I’ve built FW for this device.
The Zero Config browser is still showing both _esphomelib._tcp and _Konnected._tcp. (see attached). And the device (according to the Homeseer Log) is still rebooting every 15 minutes. In fact, as I was tying this, I had the zeroconfServiceBrowser open on my desktop and out of the corner of my eye I saw the entries for the devices disappear one at a time then reappear at the same time the Homeseer log noted it couldn’t communicate.
It doesn’t look like you’ve quite got it yet Nate.
The fix to properly disable the native API has not been done yet. I will be working on that today.
The fix requires an update to the base firmware package, so the base version number will increment. Probably will be 1.0.3. I will follow up when this is done.
@BuddyRayAtl This has been fixed! If you edit your firmware settings again, Save, and kick-off a new build, and then update it should now correctly disable the native local API (and consequently fix that every-15-minute reboot). The project version number should be 1.0.3.x where x is your incremental build number.
Honest, I did that this morning at about 9:30am EST. It built another 1.0.2 version. But I’m starting the build again and it’s saying it’s building 1.0.3.4 - so hopefully this will work!
You had asked some time ago for install photos. Since the OTA updates seem to be very reliable now I hung my units this afternoon. Photos attached. I release any copyright to these photos, feel free to use them as you wish.
That thing hanging behind my second GDO is my winch that I used to host my 5th wheel hitch in/out of my truck bed.
Let me know how it works with the updated build. I pushed the updates at about 2:45pm ET today, so this morning they would not have been included yet.
Also – I’ve ordered new power adapters with shorter cords. Also in black to match. These white ones were initially spec’d for our GDO white which has to be mounted on the ceiling near the middle of the garage so that’s why they have such long cords.
I posted in the other tread we had going about configuring blaQ that after several hours of testing it seems to be working GREAT. No errors, no warnings, and all the functions work.
I also commented in that tread about the hookup wires, they really didn’t work for me, I couldn’t get them to stay in the clamp connectors on the GDO side. The wires from the wall switch were “fatter” solid copper wires that held the clamps open too much to grab the stranded hookup wires you provided, even with the tinning. And enough of the insulation wasn’t stripped to get into the clamp. A diagram on the back of the unit says “Strip wires 7/8 in”.
Of course I can strip wires, but I found I had to solder the two wires together (the solid and stranded) then stick them into the clamp connector to get a good reliable connection on a box that vibrates and shakes as much as a GDO does. It may be that is the best and only solution, but I suspect that only a small portion of your customers are going to have a soldering iron and know how to use it :-).
Of both your wires and the GDO’s wires are solid, they can be twisted together before insertion. When you try to twist a stranded wire with a solid one, when you push it into the clamp connector, the stranded wire just slides back.
I’m being picky I know but the retired customer service manager in me can just picture the calls trying to figure out why the blaQ is intermittent.
One other nice thing - My garage ceiling is high - at least 9 feet. I dropped the blaQ, not once, but twice from that height (don’t ask). IT SURVIVED! Not even a chip or crack.
The mDNS reports correct IP address, I suspect that the old IP is stored in your server. That’s actually the part I don’t understand - when I update the FW, the IP changes. Then I have to manually add the “new” device in the app, but what happens with the old one? What’s the correct procedure?
Also, I didn’t realise that the OTA should work after the new build is ready, I was following the instructions in the email I receive after the new FW is ready.
@BuddyRayAtl Thank you for the feedback! Glad its working well now!
Good feedback about the wires. I will see if we can switch to solid core wire next time we re-order. Regarding the wire stripping, I tried to get it stripped longer but our wire supplier told me that the max they could do by machine was 7mm. Maybe will try to find a different wire supplier next time. Not the biggest deal, but the details do matter!
Did you try wiring it using the “pass-thru” method? I kinda thought that would be the cleanest way to solve for unpredictable thickness of existing wire.
@alexbk66 this may indeed be a bug where our server is overwriting the IP address. It’s supposed to update via mDNS but there may be a timing issue there because there’s a slight delay before the server returns the stored device metadata.
If you add a “new” device that’s not actually new, the app will recognize that by its mac address (deviceId) and will update the existing record. It will not create a duplicate. I’m not sure why the IP address would change after updating the firmware though. The IP address should be controlled by your router/DHCP server and it should also be fixed by MAC address, so should not change.
@nate Now you tell me
You’re right, that would have been much easier. I’m one of those guys that reads the instructions, one step at a time as I’m doing something. I really should learn to read the entire directions before starting.
I’ll check again after it’s run all night - but both blaQ’s and the Alarm Panel Pro are still working great after eight hours. From my perspective we have liftoff.
@alexbk66 The plugin AKKonnected is working great so far. And my build, upload and recognition of both the GDO and AlarmPanelPro went smoothly once I knew the right steps. But then I’m on iOS.
Yes, after set static IP - it doesn’t change anymore.
BTW, I tried adding the same device to change the old IP - but it just doesn’t seem to do anything (I tried both options) - when I click “add” it just closes the dialog and nothing happens.
I had to connect the device via USB, flash default FW, then re-flash customised FW, then the app does remove the old device from the list.
I think it should be possible in the app just to change the IP manually in the device settings?
