well nothing too serious for me I took this example as the base
The sensor itself still works perfectly
Have you seen this, I posted it approx 2 weeks ago
1.3.0 takes the names configured in the presentation oart of the sketch....
Can you post the top of your sketch (the mysensors stuff)...
I had the same issue some time ago where the sensor names that I had set in mycontroller got overwritten, most probably when I upgraded to a new release..
I fixed this by hard coding the sensor description names into the sensors presentation loop:
(copy of the most important part below)
The sensors should present themselves before they start reporting sensor data to the controller. Do these calls in your presentation()-function
void present(uint8_t childSensorId, uint8_t sensorType, const char *description, bool ack);
childSensorId - The unique child id you want to choose for the sensor connected to this Arduino. Range 0-254.
sensorType - The sensor type you want to create.
description An optional textual description of the attached sensor.
ack - Set this to true if you want destination node to send ack back to this node. Default is not to request any ack.
Description is the one for investigation..
If I am not mistaken, version 2 of the mycontroller software will support this..
// Set relay to last known state (using eeprom storage)
relay = loadState(CHILD_ID_RELAY)?RELAY_ON:RELAY_OFF;
Might not be an issue, however from a code perspective you should set the stuff below in the setup loop:
pinMode(ledPin, OUTPUT); pinMode(relayPin, OUTPUT); pinMode(ventolePin, OUTPUT); // Set relay to last known state (using eeprom storage) relay = loadState(CHILD_ID_RELAY)?RELAY_ON:RELAY_OFF;
Before() is called prior to setup... not sure if this really is an issue, but just try it...
What might help is the example from the mysensors site. It contains an example to control relays:
It does basically the same you want... can you try the example?
Some time ago my server crashed due to a faulty SD card, so I moved the database into memory. Moving the database onto a ram drive works however is not fault proof, since if the power drops, all updates since the last backup are gone.
Looking at different solutions, the best solution seems to use the SD card only for booting, and after the kernel is loaded, immediately switch to an SSD drive connected to USB.( this is now working with the great help of @Mattie for the idea and testing).
Below are the steps to get the job done.
DISCLAIMER : Before you start there are 2 things to take in mind:
(I am using an OrangePI Zero, but it should also work on other OrangePI's and Raspberry PI's)
What you need:
Order all stuff you need from the above list. put it all together and hook it up to your system.
Find the device file used by the disk
root@orangepizero:~# dmesg | grep sd [ 2.503969] sd 0:0:0:0: [sda] 61865984 512-byte logical blocks: (31.6 GB/29.5 GiB) [ 2.504938] sd 0:0:0:0: [sda] Write Protect is off [ 2.504972] sd 0:0:0:0: [sda] Mode Sense: 28 00 00 00 [ 2.505933] sd 0:0:0:0: [sda] No Caching mode page found [ 2.505965] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 2.510405] sd 0:0:0:0: [sda] No Caching mode page found [ 2.510435] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 2.511642] sda: sda1
So our disk is sda with one partition (sda1)
It is important at this stage to stop all running programs, especially mycontroller!
service mycontroller stop
and maybe some others (if present)
service mysgw stop service mcagent stop
We use a tool called rpi-clone to move all data from the SD card onto the freshly created file system:"
Download from rpi-clone from github, instructions below:
root@orangepizero:~/test# git clone https://github.com/billw2/rpi-clone Cloning into 'rpi-clone'... remote: Counting objects: 158, done. remote: Total 158 (delta 0), reused 0 (delta 0), pack-reused 158 Receiving objects: 100% (158/158), 75.00 KiB | 0 bytes/s, done. Resolving deltas: 100% (59/59), done. Checking connectivity... done.
Now goto the directory that holds the downloaded software
root@orangepizero:~/test# ll total 4 drwxr-xr-x 3 root root 4096 May 14 20:14 rpi-clone root@orangepizero:~/test# cd rpi-clone/ root@orangepizero:~/test/rpi-clone# ls README.md rpi-clone rpi-clone-setup
then rpi-clone /dev/sda
Once the copy is completed, on the OrangePI the boot env file needs to be edited so that the UUID of the SSD is used to boot the OS,
The steps below show you how to find the UUID for your SSD drive:
root@orangepizero:/dev/disk# cd /dev/disk/by-uuid root@orangepizero:/dev/disk/by-uuid# ll total 0 lrwxrwxrwx 1 root root 15 May 14 20:01 19123ccd-df7e-4863-9c9d-b775750d2d6d -> ../../mmcblk0p1 lrwxrwxrwx 1 root root 10 May 14 20:08 3d03bbd4-9294-491e-9a91-69422a9ada93 -> ../../sda1
In this example the UUID for the SSD (sda1) we are looking for is: 3d03bbd4-9294-491e-9a91-69422a9ada93
remember this sequence
vi /boot/armbianEnv.txt verbosity=1 console=both overlay_prefix=sun8i-h3 rootdev=UUID=3d03bbd4-9294-491e-9a91-69422a9ada93 rootfstype=ext4
Now add the sequence behind rootdev=UUID= (see the example above)
After the edit of armbianEnv.txt, reboot the system with the command reboot
Verify if /dev/sda1 is used after the reboot:
root@orangepizero:/boot# mount | grep /dev/sda /dev/sda1 on / type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600,data=ordered)
That's it, system is now running from the SSD instead of the sd card!