HTsensor PID issue about mycodo

[kizniche]

Sorry about that. I thought I would have caught that in testing before I pushed the update.
fixed with commit 0183a88

[zsole2]

No problem. I made a much bigger mess trying to copy back a good backup :)
Anyway, started form the beginning, everything went normal, and now checking it, looks fine.
Thanks!

[kizniche]

FYI, you should be able to just copy the backup in place of the current /home/user/Mycodo and then run "sudo /etc/init.d/mycodo initialize" to get things set up. I haven't had to go back to a previous version (I've only copied previous databases to the new version) but that should work for the entire backup.

[zsole2]

Thanks for the info...
The copying worked OK, the web interface, and relays/sensors, etc. But when I wanted to check/update to the newest version, it said that it is already the newest one. Which was obviously incorrect (it showed 3.7.74, and the newest is obviously 3.5.76). I did not now about the initialize command...

[kizniche]

Interesting. I haven't thought about the .git directory that may hinder the update if a backup is reused. I'll have to test that later. Thanks for the info, I'll reopen this as a reminder.

[kizniche]

I'm stumped as to how to properly use a backup and keep the update system working. It appears the easiest way to get caught back up is to do another clone and copy the database files in config/ to the clone.

[zsole2]

I see. In an ideal worlds, rolling back would be easy, isn't this the purpose of git?
This database copy looks strait-forward. In that case, wouldn't be enough to copy only the config directory to the backup? And keep a text file there with short instructions for the process.

[zsole2]

OK, so did some quick & dirty experimenting...

'git reset --hard '

worked to set back the state of the program (I went back 4 commits, not that I don't like the green buttons, just to make sure that it is immediately evident that it worked by seeing the blue ones).
I did not run all the things from the update script, but still worked. I guess there was no change in the symlink, init.d script, or the database...

And then the important thing: it was readily upgradeable to the newest version through the interface.

So this backup thingy may be easier than copying, just store the commit identifier... and revert back. Or even better, you can define certain stable versions that may be selected from the update screen, and you direct the update script to pull that version...

[kizniche]

I decided on the full directory backup to make sure if any custom code has been used, it isn't overwritten during the update.

I'm not well-versed in git usage. I've always stuck to the basics because that's all I've needed. I'll open an issue for improving the update/backup process, but it may not get any attention until I I read/test some of these git operations.

[zsole2]

I'm not a git wizard either, just tried the first Google tip on rolling back a repo...
Anyway, just see now that the command did not copy fully, the commit ID should be the parameter where to go back.
You are right, custom code is a valid point... I may try it later, since I just made some changes on log formatting, it is a good candidate for testing, if I screw it, nothing important is lost.