I haven’t done any coding for the Vera yet, although I suspect I will before too long, but pardon my ignorance in the mean time.
Is there a way to make tweaks to the firmware? I tried to remount some of the filesystems with -o rw,remount, but no joy.
According to /etc/mtab, /rom & /mios are mounted ro. Everything else is rw.
Short answer to your question is no, it is not possible. ROM by definition is Read Only Memory. In reality these are all system (file system) level write protected partitions. The active rootfs is structured as an “overlay”, which is the mix of rw partition on top of a ro one. This is well defined in the openWRT documentation if you want to know more.
Long answer is in a mix of two threads about the vera storage: extroot and drive usage
extroot is the only way you will be able to modify these files.
Thanks for the links. Both look interesting.
The other approach I was looking at was modifying the squashfs firmware file: extract, mod, re-squash. I can see some md5s in the writable /etc/cmh-firmware directory, but I don’t know when/where those are generated.
It’s hard to believe this hasn’t already been tried, so what doesn’t work with this approach?
What exactly are you trying to do?
Because I have only been investigating problem areas, I have not dug too deep into this but only know: The firmware squashfs only contains the writable partition of the overlay. It does not contain the kernel, the rom or mios partitions. These are getting updated by another script which gets downloaded by the upgrade initiation script. It is a two step upgrade:
- Download the upgrade script… which corresponds to the squashfs address but it really isn’t downloading that squashfs file until the next step.
- Execute the upgrade script which downloads a firmware image including all the various partitions as needed. This step calls a sysupgrade command and downloads/copy over the content of the squashfs.
The upgrade will not work by just having a custom squashfs. Unless… you are extrooted which is what I offered in the extroot thread.
It really amounts to a curiosity, honestly.
I was trying to upgrade from a URC-rebadged Lite to a Mios Edge. I backed up the Z-Wave network on the Lite and restored it on the Edge, but my URC Vivido dimmers (a.k.a. Cooper / Eaton Aspire) didn’t show up. The accessory dimmer and the Kwikset deadbolt moved over.
When the dimmers were first added in the URC firmware, they were available in the Add Device wizard by brand and model number.
I tried to re-add them in the Edge, but they weren’t in the device list by name. I extracted the firmware and found that they were indeed defined in
/www/cmh/kit/KitDevice.json with several
wizard_X.jsons defined. I haven’t really dug into the UI operations, but I’m assuming that was where all of the devices in the wizard are defined. I was looking to simply change the name of one of the other devices that is showing up, to see if that hunch was true.
It’s really not worth it for such a minuscule network, but it got my ol’ hacker juices flowing.
From what I’ve found so far, the extracted firmware squashfs does indeed have the identical filesystem structure as /mios.
I’ve seen both .sh and .squashfs firmware references. I’m assuming the .sh is the update script and that the .squashfs is the actual firmware, no?
You went a bit overkill. You can test changing that file only by editing it. If it is write only in the rootfs, it is likely a symbolic link which you can overwrite with the file itself by doing a “cp Filepath/filename Filepath/filename”
The squashfs file is only the writable part of the rootfs. It’s not the full firmware as I explained in my previous post.
Sheesh! Talk about missing the obvious
I was looking at the fact /www/cmh/kit/KitDevice.json was linked to /mios/www/kit/KitDevice.json and just blowing over the symlink would give me an editable file, since / is rw.
Okay, so I confirmed my suspicion that the file is indeed the list of devices in the wizard, although it’s still a mystery as to why the URC Vivido devices don’t show up in the list.
I’ll look more into the upgrade process.