I was hoping an emonCMS expert would answer you, because I don’t know much about emonCMS.
I think you must be updating the 30 Oct 2018 or earlier version. I think what you must do is run a full backup of your data, and then restore to the latest version. I would recommend you use a new SD Card and download and flash the latest image, rather than erasing and re-flashing the present card.
Setup → Backup → Export (tab). Click ‘Create backup’, wait and then download the file to another computer.
Alternatively, if you have a USB SD card reader you can connect to the Raspberry Pi, you can use the ‘Import USB’ tab instead.
Thanks, but your answer I cannot understand.
My version is the emonSD-06Mar24 and not from 2018.
Do the version is nearly new would I say.
Is there any expert who can help me?
Best regards
I don’t know which method it uses to recognise the version you have.
Look to see if you have this file in the ‘bootfs’ partition of your SD Card.
One of the ways is to check this file exists. I suspect it does not know “emonSD-06Mar24” is a valid name, because this version is not listed here.
If you do not have the file, make an empty file in the root of that partition called “emonSD-01Feb24” and try the update again.
If that does not help, we will ask @TrystanLea. In any case, he needs to know about the problem.
Ah - is that the mechanism then? I couldn’t work out how @Ulf had an image that was not on the list. Do you know if it looks for the file - I know Trystan writes that this is the way for people to identify the SD download - in which case my suggestion of creating a file should work.
The issue here is that EmonScripts install script generates a new image date that is custom to that particular build, @Ulf and @mnbf9rca both installed using the EmonScripts install script, hence the creation of an image date that’s not familiar.
The quick solution is to rename the image filename in the boot partition to match one that’s on the available images list. Perhaps a better solution would be to have a custom build image key in that list something like emonSD-custom-build and have EmonScripts generate that file for custom builds…?
A much better idea. Or keep the actual build date if this is important, and append ‘custom’ - then look for “custom” when testing for suitability. This will retain the individuality and avoid two potentially completely different builds from appearing to be the same, and if you parse the file name out and make it a date-time, you can still know if it can or can’t be updated.
“custom” needs to appear in the error message and logs too, of course.
@Robert.Wall & @borpin & @TrystanLea
Thanks to you.
You are right. I used the install skript and the install date would written. - crazy for my understaning..
