Navigation

    • Register
    • Login
    • OpenHardware.io
    • Categories
    • Recent
    • Tags
    • Popular
    1. Home
    2. Daniel Oliveira
    3. Topics
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    Topics created by Daniel Oliveira

    • Daniel Oliveira

      [WIP] Best practices to power your nodes
      Hardware • • Daniel Oliveira  

      3
      1
      Votes
      3
      Posts
      1596
      Views

      bjacobse

      I think you mean a smoothing cap instead of bypass cap http://www.learningaboutelectronics.com/Articles/What-is-a-smoothing-capacitor The smoothing cap for NRF24L01+ VCC/GND is not an exact science, it depends of the quality your power source can supply. If you have a battery operated device, you might not need it at all. battery is a large cap. and if using in battery operation your MCU/NRF is sleeping most of the time, and only transmitting shortly, and then sleep again to save battery lifetime. When using a AC230V -> 5 or 3,3V most converter are DC/DC and the DC signal is not smooth like a battery, to help and get this voltage signal better you need cap. The closer to NRF24L01+ VCC/GND the better. I don't believe that cheap power supplies from ebay/China are providing quality voltage... The cap size is most likely depending on how you again are using your NRF24L01+, is it continuous receiving and transmitting - like a repeater node, I recommend a large cap, if it's only transmitting occasionally and not a repeater node, you can use a smaller cap. The final cap size is usually what you have in your drawer + that can fit into your plastic housing
    • Daniel Oliveira

      [solved] MySensorWrapper - Wrapping sensor libraries for MySensors 2.0.x - need help
      Development • development programming idea visualmicro • • Daniel Oliveira  

      14
      1
      Votes
      14
      Posts
      4009
      Views

      Daniel Oliveira

      Hi! I accomplish to do what I wanted thanks to the help of you all, so I'm sharing the results I ended up with this very simple MySensorGeneric.ino that is able to manage a DHT and a BH1750 /** * Name: MySensorGeneric.ino * Created: 20-Aug-16 22:47:51 * Author: Daniel * ******************************* * * REVISION HISTORY * Version 0.1 - Development * */ #include "MySensorConfig.h" #include <MySensors.h> #include "MySensorWrapperDHT.h" #include "MySensorWrapperBH1750.h" #define CHILD_ID_LIGHT 2 #define CHILD_ID_TEMP 1 #define CHILD_ID_HUM 0 #define HUMIDITY_SENSOR_DIGITAL_PIN 3 MySensorWrapperBH1750 SensorBH1750(CHILD_ID_LIGHT); MySensorWrapperDHT SensorDHT(CHILD_ID_TEMP, CHILD_ID_HUM, HUMIDITY_SENSOR_DIGITAL_PIN); void setup() { SensorBH1750.Setup(); SensorDHT.Setup(); } void presentation() { sendSketchInfo("My Generic Sensor", "0.11"); SensorBH1750.Present(); SensorDHT.Present(); } void loop() { SensorBH1750.UpdateSensorValue(); SensorDHT.UpdateSensorValue(); wait(SLEEP_TIME); } I've created a class to manage the BH1750: MySensorWrapperBH1750.h // MySensorWrapperBH1750.h #ifndef _MYSENSORWRAPPERBH1750_h #define _MYSENSORWRAPPERBH1750_h //Need to add to project Version.h and MyEepromAdresses.h #include "MySensorsCore.h" #include <BH1750.h> class MySensorWrapperBH1750 { public: MySensorWrapperBH1750(uint8_t sensor_id); ~MySensorWrapperBH1750(); void Setup(); void Present(); void UpdateSensorValue(); private: uint8_t _sensor_id; uint16_t _lastValue; BH1750 _sensor; MyMessage _msg; }; #endif MySensorWrapperBH1750.cpp /** * Name: MySensorWrapperBH1750 * Created: 20-Aug-16 22:47:51 * Author: Daniel * Version 0.1 - Draft * ******************************* * * MySensors Wrapper for BH1750 sensor. * Wiring (I2C): * Sensor -> Arduino * GND -> GND * ADD -> NC * SDA -> A4 * SCL -> A5 * VCC -> +5V * */ #include "MySensorWrapperBH1750.h" MySensorWrapperBH1750::MySensorWrapperBH1750(uint8_t sensor_id) { _sensor_id = sensor_id; MyMessage _msg(_sensor_id, V_LEVEL); } MySensorWrapperBH1750::~MySensorWrapperBH1750() { } void MySensorWrapperBH1750::Setup() { // TODO: Set initialization mode // Default mode: // Start measurement at 1lx resolution. Measurement time is approx 120ms. // #define BH1750_CONTINUOUS_HIGH_RES_MODE 0x10 // Start measurement at 1lx resolution. Measurement time is approx 120ms. // Device is automatically set to Power Down after measurement. // #define BH1750_ONE_TIME_HIGH_RES_MODE 0x20 _sensor.begin(); } void MySensorWrapperBH1750::Present() { present(_sensor_id, S_LIGHT_LEVEL); } void MySensorWrapperBH1750::UpdateSensorValue() { // Fetch light in Lux from BH1750 sensor uint16_t newValue = _sensor.readLightLevel();// Get Lux value if (isnan(newValue)) { #ifdef MY_DEBUG Serial.println("Failed reading Light from BH1750"); #endif } else if (newValue != _lastValue) { #ifdef MY_DEBUG Serial.print("Lux: "); Serial.println(newValue); #endif send(_msg.set(newValue)); _lastValue = newValue; } } And for the DHT I've created the following class: MySensorWrapperDHT.h // MySensorWrapperDHT.h #ifndef _MYSENSORWRAPPERDHT_h #define _MYSENSORWRAPPERDHT_h //Need to add to project Version.h and MyEepromAdresses.h #include "MySensorsCore.h" #include "DHT.h" class MySensorWrapperDHT { public: MySensorWrapperDHT(uint8_t sensor_temp_id, uint8_t sensor_humd_id, uint8_t sensor_pin = 3); ~MySensorWrapperDHT(); void Setup(); void Present(); void UpdateSensorValue(); private: uint8_t _sensorTempId; uint8_t _sensorHumdId; uint8_t _sensorPin; DHT _sensor; MyMessage _msgTemp; MyMessage _msgHumd; float _lastTempValue; float _lastHumdValue; }; #endif MySensorWrapperDHT.cpp /** * Name: MySensorWrapperDHT * Created: 20-Aug-16 22:47:51 * Author: Daniel * Version 0.1 - Draft * ******************************* * * MySensors Wrapper for DHT sensor. * Wiring (): * Sensor -> Arduino * GND -> GND * OUT -> D3 * VCC -> +5V * * NOTE: If using a board with 3.3V logic like an Arduino Due connect pin 1 * to 3.3V instead of 5V! * Connect pin 2 of the sensor to whatever your DHTPIN is * Connect a 10K resistor from pin 2 (data) to pin 1 (power) of the sensor * https://github.com/adafruit/DHT-sensor-library/blob/master/examples/DHTtester/DHTtester.ino */ #include "MySensorWrapperDHT.h" MySensorWrapperDHT::MySensorWrapperDHT(uint8_t sensor_temp_id, uint8_t sensor_humd_id, uint8_t sensor_pin) { _sensorTempId = sensor_temp_id; _sensorHumdId = sensor_humd_id; _sensorPin = sensor_pin; MyMessage _msgTemp(_sensorTempId, V_TEMP); MyMessage _msgHumd(_sensorHumdId, V_HUM); } MySensorWrapperDHT::~MySensorWrapperDHT() { } void MySensorWrapperDHT::Setup() { _sensor.setup(_sensorPin, DHT::DHT22); } void MySensorWrapperDHT::Present() { present(_sensorTempId, S_TEMP); present(_sensorHumdId, S_HUM); } void MySensorWrapperDHT::UpdateSensorValue() { // TODO: really needed? wait(_sensor.getMinimumSamplingPeriod()); // Reading temperature or humidity takes about 250 milliseconds! // Sensor readings may also be up to 2 seconds 'old' (its a very slow sensor) float currentTempValue = _sensor.getTemperature(); float currentHumdValue = _sensor.getHumidity(); // Check if any reads failed and exit early (to try again). if (isnan(currentTempValue) || isnan(currentHumdValue) ){ Serial.println("Failed to read from DHT sensor!"); } else { // Update temperature from DHT sensor if (currentTempValue != _lastTempValue) { _lastTempValue = currentTempValue; send(_msgTemp.set(currentTempValue, true)); #ifdef MY_DEBUG Serial.print("Temp: "); Serial.println(currentTempValue); #endif } // Update humidity from DHT sensor if (currentHumdValue != _lastHumdValue) { _lastHumdValue = currentHumdValue; send(_msgHumd.set(currentHumdValue, 1)); #ifdef MY_DEBUG Serial.print("Hum: "); Serial.println(currentHumdValue); #endif } } } And to my surprise the footprint after compiling is even smaller, 18,374 bytes (59%) of program storage space and 913 bytes (44%) of dynamic memory with a single .ino versus 17,748 bytes (58%) of program storage space and 857 bytes (42%) of dynamic memory the above project in VisualMicro. Both results with MY_DEBUG defined. Next step is to create classes to manage switches, relays and LEDs. Once again thank you all for the help and fell free to share your opinions about the way I'm trying to do things. Best regards
    • Daniel Oliveira

      Alternative to ArduinoIDE
      General Discussion • • Daniel Oliveira  

      29
      0
      Votes
      29
      Posts
      8033
      Views

      stedew

      @andrew Hello Andrew, as Anticimex already answered also other IDE's are possible (Atmel Studio with a arduino plugin seems to work) Atom, and others I use the Eclipse + plugin solution and are happy with it. It is really a powerfull solution with many configuration options. I had a few discussions with the maintainer of sloeber (Jantje) and in general i made a few observations that summerize yours: lsee discussions on github The problem for cpp is that you have to declare the prototypes because you lose the confort from the ino suffix. Regards , Stefan
    • Daniel Oliveira

      New Project with MySensor network and autonomous nodes
      My Project • • Daniel Oliveira  

      7
      0
      Votes
      7
      Posts
      3677
      Views

      John

      With PiDome you are able to add options to device skeletons you create (so you can re-use devices). When you add a device to the server you can set these options. Example: You have 5 temperature nodes, you create a skeleton once with your temperature node setup, you add the option poll time with a drop down choosing between 1, 5, 10 minutes (you can also use input fields off course). When you add these devices to the server you then can set the polling time per device. By using the mysensors functionality to do a data request you will be able to get the option's value (See "Requesting data" on the API page: http://www.mysensors.org/download/sensor_api_15). But. The above does not work yet for PiDome as this is not implemented in the mysensors plugin. Too be honest i did not even have thought about it. I have created a feature request for the mysensors plugin to have this implemented at: https://bitbucket.org/pidome/pidome-mysensors/issues/4/be-able-to-create-options-for-devices-in So if you are going to use PiDome or not, this will be implemented (so other users will also be able to use it when it becomes available). I can not yet give an estimate on when this is implemented as the Custom devices editor is on the optimization list, and currently i'm extremely busy with the raspberry pi client to have it compatible on multiple display resolutions (starting from 240*320). You have the possibility to vote for the option so it can go up on the prio list (It is the three of PiDome deciding which option is next to pick up). Regarding of booting all the sensors at the same time. The server does not care. It is capable of handling bulk messages from the gateway. So you need @hek to answer this one.