It doesn’t look like you followed the steps to get it reset to the 2.43 firmware.
Hi Fly,
Sadly I don’t get to reset the hub firmware because, from this set of instructions, I don’t get the two firmware files (.bin) after running the “pethublocal setup” so can’t reboot the hub as directed for the downgraded firmware.
I’ve now read through the code and I think the python fails with the log message, I mentioned above (link) because, in the first stage a 1.177 firmware file is downloaded then deXor’s to return a key, which is used in the 2nd stage, but because the first file is empty, then the second stage fails to Xor the 2.43 bin file.
So bottom line, I have no firmware files to use to reset the firmware to 2.43.
IIRC, holding in the reset button and plugging it in resets the firmware to default. That process is somewhere on @peterl’s Github page.
Magic! Thanks Fly. I’ll try that a little later today.
1 Like
Hi Fly,
I tried the reset button method you mentioned, but sadly the hub remains on the 233.xx version (tried a few times). Do you know of a way to force a compile of the 2.43 firmware without using the “pethublocal setup” option?
C
I don’t have time to look right now, but I’m 99% sure the steps to reset are in his github docs.
I didn’t think it was so clear, that if the hub succeeded in downgrading the firmware or not. I could not see the firmware version. Maybe in the log files? In the pethub config file there was only the original firmware version I think. It’s hard to remember all steps, especially if you have to tinker a lot to get it up and running.
Are your DNS poisoning working as it should?
Hi Pum,
Yes the DNS poisoning works as defined. The setup process find the correct internal and external addresses perfectly. The script finds the cloud account, extracts all the data for the hub, pwr door and pets and creates the related config files BuT when it asks if I want to download the firmware, it starts the process but then fails.
My assumption, based on reading the code, is that the script has three stages. 1) downloads a v1.177 bin file, 2) extracts the long code from it then 3) uses that code to create a new bin file for my hub.
Because the first bin is not found it can’t extract the king code and therefore can’t create the new hub firmware.
Thanks Fly,
Yes, I have seen this and, short of opening the hub and connecting wires to it, I followed this to the letter.
The “After the configuration is built using pethublocal setup the current directory should have two groups of firmware images” from the below extract, is where my problem starts. I don’t get the “… two groups of firmware images…” so no matter how often I press the reset button on the hub, it’s not going to downgrade the firmware.
The reason for the missing two firmware images is found here… " …during the setup when downloading the current firmware from SurePetCare the script finds the XOR key for that firmware as the project includes the DeXORed 2.43 firmware and builds a hub specific image with the XOR key just found…" - the “when downloading the current firmware from SurePetCare” doesnt happen, so the script cannot find “**the XOR key for that firmware" and so cannot "build[s] a hub specific image with the XOR key just found**”
Unless I can download an image manually, then edit the script to run from that point on, I’m never going to get the 2nd firmware image.
" If your Firmware above is not
2.43and2.201or anything higher then you will need to flash on the older firmware to make it work. Thankfully I have made this as straight forward a process as possible as during the setup when downloading the current firmware from SurePetCare the script finds the XOR key for that firmware as the project includes the DeXORed2.43firmware and builds a hub specific image with the XOR key just found.After the configuration is built using
pethublocal setupthe current directory should have two groups of firmware images:H0xx-0xxxxxx-2.43-nn.binand
H0xx-0xxxxxx-1.177-nn.binWhere
H0xx-0xxxxxxis your Hub Serial Number and2.43version of files is the custom firmware built to your Hub, and1.177is what was downloaded from SurePet and then the XOR key found as1.177is the version of the bootloader on the hub, which I hope SurePetCare don’t upgrade to lock me out of doing thisThe Hub requests the firmware over
HTTPon port80tohub.api.surehub.ioso we are in luck as it doesn’t check the certificate and will download fine from PetHubLocal… hence why we can downgrade and upgrade without the issue of the need to validate a Certificate over HTTPS.
Hi Fly, I found and used the "pethublocal firmware -sn Hxxx-xxxxxxx -f " command and this is the output (below). You can see from the error, it’s just not finding the 1.177 firmware at the http://35.168.106.54/api/firmware address.
Any help on where I might find my hub’s firmware would be a huge help.
INFO:pethublocal:Download Firmware Serial Number: H010-0XXXXXX
INFO:pethublocal:SureHub Host hub.api.surehub.io IP Address: 35.168.106.54
INFO:pethublocal:Downloading first firmware record to get header information
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): 35.168.106.54:80
DEBUG:urllib3.connectionpool:http://35.168.106.54:80 “POST /api/firmware HTTP/1.1” 200 0
Traceback (most recent call last):
File “/usr/local/bin/pethublocal”, line 8, in
sys.exit(cli())
File “/usr/local/lib/python3.9/site-packages/click/core.py”, line 1130, in call
return self.main(*args, **kwargs)
File “/usr/local/lib/python3.9/site-packages/click/core.py”, line 1055, in main
rv = self.invoke(ctx)
File “/usr/local/lib/python3.9/site-packages/click/core.py”, line 1657, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File “/usr/local/lib/python3.9/site-packages/click/core.py”, line 1404, in invoke
return ctx.invoke(self.callback, **ctx.params)
File “/usr/local/lib/python3.9/site-packages/click/core.py”, line 760, in invoke
return __callback(*args, **kwargs)
File “/usr/local/lib/python3.9/site-packages/click/decorators.py”, line 26, in new_func
return f(get_current_context(), *args, **kwargs)
File “/usr/local/lib/python3.9/site-packages/pethublocal/cli/init.py”, line 50, in firmware
log.info(download_firmware(serialnumber, force))
File “/usr/local/lib/python3.9/site-packages/pethublocal/functions.py”, line 103, in download_firmware
recordcount = int(byte[2], 16) + 6
IndexError: list index out of range
I wonder if they changed something to prevent this. 
I’ll try to check and see if it works for me later today.
Hi everyone,
I must admit I don’t use HA, but Peter’s great work should also be usable outside the HA world, I assume. In the end I need to make use of the MQTT messages being sent by pethublocal in my FHEM installation. 90 % of the time I spent on the setup was due to my Truenas Scale K8s Setup, especially with the core requirements on ports (80,443) and the Mosquitto setup. But I guess I managed now to get it working, at least I believe so. The hub is connected, ears are solid green and it sends messages via MQTT to mosquitto. Also the information in the pethublocal frontend looks promising.
My question is now related to what pethublocal actually sends via MQTT. When looking at the topics received at mosquitto they are:
- pethub/hub
- pethub/ha
I am pretty sure that during my testing (aka struggeling during setup) I also saw a “homeassistant” topic, which seems to be the enhanced information sent by pethublocal.
Can someone confirm this? And if yes, what is missing / probably going wrong if this information is missing?
Thanks everyone and especially to Peter. Fantastic work and brilliant documentation.
Cheers
The messages that go into /hub are the Hub messages to and from the hub as both PHL and the hub itself post to the same topic and the /ha ones are the translated version.
If you want some light reading on all the different mesasges.
Thanks Peter. So you are saying If I am having the pethub topic I have all I need or is there still something missing? As said, I thought I also saw a topic “homeassistant” popping up during setup, but I might be wrong obviously.
Hi Colin - hitting the same issue, just opened a GitHub issue Firmware download fails - IndexError: list index out of range · Issue #23 · PetHubLocal/pethublocal · GitHub
Did you ever manage to progress further?
Hi, Sadly no. I gave up. I think I know what the issue is, but just don’t know how to resolve it. (it’s that v1.177 firmware file, I don’t think it exists. The script is unable to download it & parse it, so throws the “…out of range…” error. If that step could be corrected, there’d be a file to parse.
Fly suggested I reboot the hub and press the little reset button at the same time…tried that about 20 times before giving up on that too.
Anyway, I have the cloud integration working so at least I can lock and unlock the door, even if horribly slow.
C
Any chance you still have your log file and could privately share your serial and bootloader version? Seems easy enough to try and do an interactive POST request to see what happens when the firmware is requested.
Sadly, I’m not using pethublocal right now, so I don’t have a log with my serial/bootloader. FWIW, there’s no real risk in sharing that info, but PM is probably best just in case.
edit: Or if you want to try it yourself, all the needed code is under download_firmware_record in functions.py.
My firmware still downloads but I have tested other serial numbers and it apparently only works for numbers between H010-0622744 and H010-0666595. Maybe you are outside that range?
1 Like