Recovery for rooted hubs

CloneNum3
Site Admin
Posts: 107
Joined: Wed Jan 07, 2015 10:02 am

Recovery for rooted hubs

Postby CloneNum3 » Mon Apr 20, 2015 12:53 pm

Just follow the 00.86 update procedure. As long as you currently have SSH, the update procedure is normal.

Once at 00.86, I have re-added my 00.86 hub via the iPhone app (was blinking purple at the time) without doing anything special. Rebooted, got a blue light, all was well.

I can add and/or control my lights via SSH just fine.

Adding two lights:

Code: Select all

[root@flex-dvt ~]# aprontest -a -r zigbee
Add device for Zigbee
Waiting for 1 callbacks...
New Zigbee node: 2


Turning light #3 off then back on:

Code: Select all

[root@flex-dvt ~]# aprontest -u -r zigbee -m 3 -t 1 -v OFF
Update device with master ID 3, setting value OFF for attribute 1
[root@flex-dvt ~]# aprontest -u -r zigbee -m 3 -t 1 -v ON
Update device with master ID 3, setting value ON for attribute 1
[root@flex-dvt ~]#


-Clonenum3

winkertinker
Posts: 1
Joined: Thu Jun 30, 2016 1:17 am

Re: Recovery for rooted hubs

Postby winkertinker » Tue Jul 05, 2016 4:34 pm

I want to add something that I believe you suggested in XDA forums, which was to alter the cf_fver3 file to trick the servers into updating you.
this entire ordeal took several weeks to complete as I am working on many complicated problems right now and while I am familiar with linux, I have very little admin practice so the shell and commands are completely foreign to me. Clone, your instructions are among the clearest, easiest to follow I have ever found, and even still, I had to teach myself linux just to root this dang thing. :lol:

I gotta say though, I am beginning to like using the terminal more and more as i learn more and more about all the commands and tricks that are taken for granted. it's difficult for someone with ADD to keep track of all that, so I rely on my OCD side for that.

Being both ADD and OCD is not for the feint of heart. It works like quantum superposition;
sometimes they add up, sometimes they cancel each other out, which makes sense because brainwaves.

anyway,

I started with a stock hub at .86, but when I tried to update it, after I initially thought I had it rooted, it kept giving me the same recovery message as if it were damaged by the same SNAFU from Wink. Except my hub never had that problem and they supposedly fixed it before I even tried to update - strange.

so it said it was updated, but the version number in the wink app was reported as 0.00.00

I believe the problem was caused by the hub being partially rooted? if is that even a thing?

So I tried to update it again, as the option was available but it refused to update, giving me the recovery message instead.
also, FYI, not sure if it matters or not but the recovery message from the Android app was slightly different from the one in iOS.


did some digging, I found your suggestions and initially I set the cf_fver3 file to zero and it started to update, but the update kept failing - it was already at 0 but the file was blank I think.

So I tried to guess which version of the software it had by trying all the version numbers I could find mentioned in the forums, until it finally downloaded 2.49 and things seemed to be working. I'm not even sure which one got it to work as I was in zombie mode at this point.

So I rebooted a few times, made sure it was still rooted, played with the app, firmware still displayed 2.49 consistently, recovery message was gone, i remember noting that before I got to 2.49 the app said I needed either 2.49 or 2.66 to use the lights. after seeing some warning for 2.66 around the forums, I attempted to stick to 2.49. but now I get a new update message, tried to connect some Osram Lightify lights, they didn't connect.

Looked around the filesystem with WinSCP copied some files but at this point my eyes and mind were glazed over several times, so I said FUUUUU!!!! and upgraded it again.

congrats, I was now at 2.66 and the recovery message was completely gone and far as the app was concerned, the hub was now in perfect working order.

EXCEPT - the damn lights will would not connect, tried aprontesting, I added the api folder for blink tried to add them there and even tried manually adding items to the database using "aprontest -n" - it didn't work, but the error I got from that was slightly different

some more clues that something was wrong with the hub's software were the *.ota files
I was missing a few that others said they had, can't remember which ones now.
and when I tried to add the zigbee device manually, it gave me "Error 1 on Command 1"

I could not find what this meant, there is virtually no data about aprontest and how it works, other than what we have here.
but I finally noticed something interesting right around this point in the boot sequence which is why I prefer a hard wired or at least an independent serial connection:


Code: Select all

app_boot=run appboot_args && nand read ${loadaddr} app-kernel 0x00400000 && bootm ${loadaddr}
app_boot_bad=run updater_args; setenv bootargs ${bootargs} badapp; nand read ${loadaddr} updater-kernel 0x00300000; bootm ${loadaddr}
boot_app=run app_boot || run app_boot_bad
app_boot_bad=run updater_args; setenv bootargs ${bootargs} badapp; nand read ${loadaddr} updater-kernel 0x00300000; bootm ${loadaddr}
File '/var/lib/database/apron.db' does not look like an Apron database file
Zigbee NCP is up to date
root: Starting crond
root: Starting network



File '/var/lib/database/apron.db' does not look like an Apron database file


which begs the question: what does an Apron database file look like? I have no frame of reference for this whatsoever. I'm a techie, I take everything apart but I like GUIs, specifically many of the GUIs used in star trek and other cool scifi stuff - that's why I got this hub in the first place. I want to press as few buttons as possible to get what I want from my computers. So this is going to be part of a much larger system, a real JARVIS with a real AI that actually learns and is useful and practical - more on that later.

no data for this apron gateway anywhere, but I see SQlite mentioned a lot, so I did the dangerous thing and made the assumption that being a database file, it had to be related to SQL - something else I know nothing about. At this point, I started getting flashbacks to the early days of rooting Android - database file permissions.

I went through the folder it mentioned and played with the permissions, until I realized I understood and remembered nothing about linux permissions.

Back to school - a bunch of let's say herbal medication and an hour or so of thenewboston videos later I'm finally understanding some of these shell commands -- and file permissions.

so after changing apron.db permissions to no avail, I made the same changes to the database folder, SQLite - but nothing happened.


I reset what I changed then started looking for other things that may be related, eyes glazed over again, tired but determined, mindlessly browsing files using winSCP I stumble upon what looks like a backup of the apron file I made, which I think was one of your suggestions Clone, in the initial rooting stage.

Bear in mind this is nearly a month and a repainted house later. So being lazy and in not giving a FUUUUUUUU mode, I decided to overwrite the file it was complaining about with a copy of the backup.

I rebooted from the command line,
then this happened:

Code: Select all

app_boot=run appboot_args && nand read ${loadaddr} app-kernel 0x00400000 && bootm ${loadaddr}
app_boot_bad=run updater_args; setenv bootargs ${bootargs} badapp; nand read ${loadaddr} updater-kernel 0x00300000; bootm ${loadaddr}
boot_app=run app_boot || run app_boot_bad
app_boot_bad=run updater_args; setenv bootargs ${bootargs} badapp; nand read ${loadaddr} updater-kernel 0x00300000; bootm ${loadaddr}
Starting database version is 0
Upgrade 0 => 1 ...
... Good; transaction controls detected.
[-OK-] Patch 0 => 1
Upgrade 1 => 2 ...
... Good; transaction controls detected.
[-OK-] Patch 1 => 2
Upgrade 2 => 3 ...
... Good; transaction controls detected.
[-OK-] Patch 2 => 3
Upgrade 3 => 4 ...
... Good; transaction controls detected.
[-OK-] Patch 3 => 4
Upgrade 4 => 5 ...
... Good; transaction controls detected.
[-OK-] Patch 4 => 5
Upgrade 5 => 6 ...
... Good; transaction controls detected.
[-OK-] Patch 5 => 6
Upgrade 6 => 7 ...
... Good; transaction controls detected.
[-OK-] Patch 6 => 7
Upgrade 7 => 8 ...
... Good; transaction controls detected.
[-OK-] Patch 7 => 8
Upgrade 8 => 9 ...
... Good; transaction controls detected.
[-OK-] Patch 8 => 9
Upgrade 9 => 10 ...
... Good; transaction controls detected.
[-OK-] Patch 9 => 10
Upgrade 10 => 11 ...
... Good; transaction controls detected.
[-OK-] Patch 10 => 11
Upgrade 11 => 12 ...
... Good; transaction controls detected.
[-OK-] Patch 11 => 12
Upgrade 12 => 13 ...
... Good; transaction controls detected.
[-OK-] Patch 12 => 13
Upgrade 13 => 14 ...
... Good; transaction controls detected.
[-OK-] Patch 13 => 14
Upgrade 14 => 15 ...
... Good; transaction controls detected.
[-OK-] Patch 14 => 15
Upgrade 15 => 16 ...
... Good; transaction controls detected.
[-OK-] Patch 15 => 16
Upgrade 16 => 17 ...
... Good; transaction controls detected.
[-OK-] Patch 16 => 17
Upgrade 17 => 18 ...
... Good; transaction controls detected.
[-OK-] Patch 17 => 18
Upgrade 18 => 19 ...
... Good; transaction controls detected.
[-OK-] Patch 18 => 19
Upgrade 19 => 20 ...
... Good; transaction controls detected.
[-OK-] Patch 19 => 20
Upgrade 20 => 21 ...
... Good; transaction controls detected.
[-OK-] Patch 20 => 21
Upgrade 21 => 22 ...
... Good; transaction controls detected.
[-OK-] Patch 21 => 22
Upgrade 22 => 23 ...
... Good; transaction controls detected.
[-OK-] Patch 22 => 23
Upgrade 23 => 24 ...
... Good; transaction controls detected.
[-OK-] Patch 23 => 24
Upgrade 24 => 25 ...
... Good; transaction controls detected.
[-OK-] Patch 24 => 25
Upgrade 25 => 26 ...
... Good; transaction controls detected.
[-OK-] Patch 25 => 26
Upgrade 26 => 27 ...
... Good; transaction controls detected.
[-OK-] Patch 26 => 27
Upgrade 27 => 28 ...
... Good; transaction controls detected.
[-OK-] Patch 27 => 28
Upgrade 28 => 29 ...
... Good; transaction controls detected.
[-OK-] Patch 28 => 29
Zigbee NCP is up to date
root: Starting crond
root: Starting network



I'm guessing that meant the file I threw in there "looked like an apron.db file", but needed to be updated since it was from an older version of the firmware. And I can now connect my lights and have root access on firmware 2.66

there are still some other minor error messages,
but the hub works, can control lights using stock set up with echo, android, and ios while still having full root access

so thank you Clone for taking the time to compile this information, the rest of it is so fragmented and this hub is so worth the effort and I wanted to share my little adventure with you and everyone here in the hopes that it will save someone else some time and frustration.

I will be posting more details about my efforts in the appropriate sections.


Return to “Recover from April 18th 2015 Wink Snafu”

Who is online

Users browsing this forum: No registered users and 1 guest