I'm very interested by your setup. It has been a shame to have some low voltage power in order to measure power consumption
I hope you can display something soon.
Regards,
Just to let you know that I solved the issue.
I found a library where you can control the speed and make sure it get to it's position.
You can find it here: https://github.com/netlabtoolkit/VarSpeedServo
I incorporated it in the Mysensor sketch and it works eventhoug it looks like it only goes like 90 degrees but it's enough for me :
#include <MySensor.h>
#include <SPI.h>
#include <VarSpeedServo.h>
// #include <Servo.h>
#define SERVO_DIGITAL_OUT_PIN 3
#define SERVO_MIN 0 // Fine tune your servos min. 0-180
#define SERVO_MAX 180 // Fine tune your servos max. 0-180
#define DETACH_DELAY 900 // Tune this to let your movement finish before detaching the servo
#define CHILD_ID 10 // Id of the sensor child
MySensor gw;
MyMessage msg(CHILD_ID, V_DIMMER);
VarSpeedServo myservo; // create servo object to control a servo
// a maximum of eight servo objects can be created
// Servo myservo; // create servo object to control a servo
// a maximum of eight servo objects can be created Sensor gw(9,10);
unsigned long timeOfLastChange = 0;
bool attachedServo = false;
void setup()
{
// Attach method for incoming messages
gw.begin(incomingMessage);
// Send the sketch version information to the gateway and Controller
gw.sendSketchInfo("Servo", "1.0");
// Register all sensors to gw (they will be created as child devices)
gw.present(CHILD_ID, S_COVER);
// Request last servo state at startup
gw.request(CHILD_ID, V_DIMMER);
}
void loop()
{
gw.process();
if (attachedServo && millis() - timeOfLastChange > DETACH_DELAY) {
myservo.detach();
attachedServo = false;
}
}
void incomingMessage(const MyMessage &message) {
myservo.attach(SERVO_DIGITAL_OUT_PIN);
attachedServo = true;
if (message.type==V_DIMMER) { // This could be M_ACK_VARIABLE or M_SET_VARIABLE
int val = message.getInt();
myservo.write(SERVO_MAX + (SERVO_MIN-SERVO_MAX)/100 * val,255,true); // sets the servo position 0-180
// Write some debug info
Serial.print("Servo changed. new state: ");
Serial.println(val);
} else if (message.type==V_UP) {
Serial.println("Servo UP command");
myservo.write(SERVO_MIN,255,true);
gw.send(msg.set(100));
} else if (message.type==V_DOWN) {
Serial.println("Servo DOWN command");
myservo.write(SERVO_MAX,255,true);
gw.send(msg.set(0));
} else if (message.type==V_STOP) {
Serial.println("Servo STOP command");
myservo.detach();
attachedServo = false;
}
timeOfLastChange = millis();
}
In deep Sleep the cunsumption is below 19µA, but i have to send with PA_MAX. On some Windows the open/close frequency is verry high, so the battery is to fast emty.
The CR2032 is good, but i want more "lifetime"
@NeverDie Thx for appreciating the work done. There will also be an open source part in the future. When and how extensive the open source part will be, remains to be seen. The release of certain information (block diagram, ..., in this post) is related to those open source parts.
There are some OBD solutions, however most of them (in my experience) give back low frequency data put by the car manufacturer on the OBD-bus (CAN, ...). Therefore transients evolving directly from the battery could only be recorded if the manufacturer sends those data accordingly on the bus. Due to the small bandwidth(also because of other car data that have to be sent, ...), such battery data are sent more often once per second or less. Fast battery events (i.e. cranking events, ...) are therefore imperceptible. Unless the manufacturer processes the fast events and then sends them (once per second or less), which is very unlikely if the manufacturer does not market this feature itself. Third parties devices for high frequency sensing costs several hundreds dollars.
In my experience, important battery states (especially the fast ones) are recorded by measuring and processing corresponding data directly on the battery.
I agree with you about the limits related to the communication over Bluetooth. But i think Bluetooth 5.0 will improve a lot. However, WiFi will always remain an important option due to the high data throughput. The combination of both (BLE & WiFi), especially with regard to energy consumption, will gain in importance.
I am non technical but I have 8 wirsbo stats in my house. One of them is faulty and the unit is now obsolete. Is it possible to purchase one of these pcbs and use it to replace the one in the faulty stat ?
Thanks
Richard
@tsunami My setup is max 50m radius and 433MHz standard power RFM69s so a small 1/4 wave whip works reliably even from a below ground pump chamber 10m away.
Your 915MHz at 200m SHOULD work on 1/4 wave if obstacle free line of sight, but you could try a 2.4GHz Wifi router at one location and use a mobile at the other to test if you can see the router. I can see at least 3 neighbouring routers identified on my mobile from over 40m away through masonry, 10 on the laptop, so it's a simple enough test.
If you can see the router on either, 915MHz should be rock solid with a simple whip and no need of directional antenna.
