Hi. I bought the emonTx shield and wired it up to a RaspberryPi. The Pi then got a clean install of EmonPi with a minor modification to put the filesystem on a USB stick so the SD card is just used for booting. Low-write mode serves no purpose here, but is set up by default. I can’t seem to work out how to turn it off. It wouldn’t be an issue, but a few of my 1-wire sensors mis-fire from time to time and I get values of 85°. The API methods for removing old data points report success but don’t actually do anything.
Run $ rpi-rw
(And $ rpi-ro to go back again, should you wish.)
85°C is intended as an error value, it’s hard coded as the initial value in the sensor, and there’s nothing that can be done about it. (It cannot be trapped, because it also might be, depending on your application, a perfectly valid value).
Just based on the experience with my emonPi the $ rpi-rw is just temporary. There must be a cron or some routine that sets the emonPi back into read only mode. @glyn.hudson (or someone?) would have to answer how to permanently turn off the read-only mode.
The “read-only” OS is as much about locking it down to minimize accidental changes as it is “low-write”.
The read-only configuration would need reversing rather than “turning off” even when using “rpi-rw” you are temporarily mounting a read-only file system as writeable, it is still optimized for read-only, just temporarily writable.
If using a hdd and not needing the safety of read-only or the low-write optimization then re-enabling swap space, reclaiming RAM used by /var/log and cache etc would all bring benefits, not to mention the persisting logfiles etc.
The temporary RW status from using “rpi-rw” will be remounted RO every hourly anniversary from boot time due to ntp-backup and also by any other routines that use “rpi-rw” and “rpi-ro” for scheduled eg back-ups or user initiated tasks such as emonpi update.
I was under the impression that @JonSenior wanted to make it writeable only to edit the data, so it would not matter if/when it reverted to read-only.
But as the original problem was the DS18B20 returns 85 °C, which is the value written into the temperature register at power-on, maybe the reason why it reset, didn’t convert the temperature and store it in the register, or didn’t get asked to do that, before being asked to send the register contents, is what we should be asking?
Me too! but
is a little ambiguous I guess, “rpi-rw” is probably the best answer but in response to
I thought I would explain RO isn’t just about low-write and that it should be left as is or undone to benefit from either status, “turning it off” by temporarily mounting a read-only file system RW on a permanent basis isn’t the way to go and it could go back to RO for a number of reasons.
OK. There’s two ideas at play here, RO and low-write. RO has been taken care of, everything but the boot partition is mounted on a flash drive and the mount points are defined as RW in fstab.
It’s low-write that’s killing me. My data is in a PHPFINA format and a consequence of low-write mode is that data cannot be edited once written (I don’t remember where I read that but I found it in one or two places). I have write access to the data files (this is always the case, even in RO mode which just protects the configuration files). I should make it clear that I’m fairly comfortable with Linux, it’s the emoncms specifics that I’ve not got my head around.
Thanks,
Jon
There are reports that flash drives are subject to the same level of wear failure as the SD cards, they are essentially the same tech in many cases. It is up to you to decide on whats right for you and the medium you choose. A spinning disk hdd would be a better solution otherwise low-write precautions should be taken.
The predominant factors for low-write are the buffered disc write and the limited feature set imposed to restrict the use of write intensive feed engines and processes. The edit/insert functions were disabled for 2 reasons mainly, firstly the buffered write means it is difficult to know were the data at the time (ie in the buffer or on disk) and also because to edit on datapoint a whole cluster on-disc has to be rewritten, so if you had to edit 100 points close together it may result in that sector being rewritten 100x times, once per edit.
The differences in the “normal” verses “low-write” emoncms (not the OS) are all controlled via the settings.php, there are different default files for each configuration, so that would be a good place to start, you can also stop the feedwriter service and stop it from starting at boot once you are configured out of “low-write” mode.
emonPi (AKA low-write) default settings.php
and standard default settings.php
Hi Paul, Im using emoncms at my VPS running Ubuntu 18.04 in hosting center. After 3 years of excellent run of version 9.8.28 I have decided to switch to another server with last version 10.2.7. But problem for me seems to be lowwrite version. Especialy when I create or modify template for Device Module (I have my own devices with customised set of inputs and feeds), Device module doesnt see new template until I push Flush button at Redis section of Admin page. And it is unpleasant complication. In my old version I never had such an issue. As I like new UI of 10.2.7 version, I would like to use that, but I would like to switch-off correctly low-write functionality, as my old instalation was prefetcly working without that. Is there any system switch how to switch-off low write and to operate version 10.2.7 in “no low-write” mode correctly? Or do you have any recommendation for me?