Navigation

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

    Best posts made by novicit

    • RE: How best to find the "best" small solar panel of a particular size?

      I just completed a battery-free outdoor node reporting temp/humid based on the information in this thread. Works great, thanks to @NeverDie for his insights. Node is a sensebender micro, RFM69W, 10F supercapacitor, and 5V solar panel. Reporting every 4 minutes it sends temp, humid, supercap %, & solar V. Uses the simple tiny solar charger schematic from @NeverDie shown above.

      Results: The supercapacitor cost $2 at Digikey, is about 2/3 the size of a AAA battery, and lasts 40 hours without the solar panel connected. The 40 hours is when the supercapacitor reaches 1.9v as the low end for operating the node. Easily gets through the longer dark winter nights.

      The solar panel is from China, Ebay, 110mmx70mm, 5V, 1.25W. The panel works great also. It reaches 4V in the smallest amount of light, and 5.45V (no load) in modest indirect light. In fact, it will fully recharge the supercapacitor in the morning before the sun even rises above the horizon, just from the sky brightening. (From the ~20% overnight discharged state.) It seems to charge a fully empty supercap in ~10 minutes under average light.

      Bottom line: no longer walking through 1ft of snow in 10 degrees (F) to get the node, bring it inside, remove water seals, and change the batteries. This is the solution I was looking for.

      Also have a 2nd outside node in testing using the Ceech solar board (A great PCB also!), a 18650 battery and the same solar panel. So far the battery has gone 2 months and is at 3.85V without the panel connected. In testing, the solar panel has no problem charging the battery. In fact so much, I am going to add a FET to disconnect the solar panel periodically to allow the battery to cycle some.

      This site is excellent, such great talent, thank you all!

      posted in Hardware
      novicit
      novicit
    • RE: nRF5 action!

      @sebi,
      A couple weeks ago I began exploring deploying E73 modules and had to remove protections. I was successful and now have a working E73 ethernet gateway. Only had ST Link-V2, so I used a "blue pill" I had in inventory to load it with Black Magic Probe. This cleared the protections.

      The instructions I followed to load the BMP are step-by-step at https://github.com/TamojitSaha/STM32f103_Black-Magic-Probe

      The instructions followed to clear protections with BMP also are step-by-step and worked perfect. They are at https://github.com/AndruPol/nrf52832-recover

      In item #4, the program arm-none-eabi-gdb.exe seems to be part of the Arduino tool chain as I found it just by doing a search in file explorer and it was already on my win10 machine. Also, in item #4, (gdb) is the prompt that the program arm-none-eabi-gdb.exe gives. In the first line, change the '/dev/ttyACM0' to your com port. Use 'quit' to exit the program. Also, use 'mon help' to see options.

      There are apparently a number of ways to 'recover' the E73, but this worked easily for me, and was step-by-step.

      posted in My Project
      novicit
      novicit
    • RE: Zigbee gateway with support for multiple vendors?

      @mfalkvidd Please keep us informed on how this goes for you.

      A few months ago I also implemented a zigbee network for similar reasons. The nodes are very inexpensive, small, and coin cell powered. I am using these for common applications like temp or motion. That way I can use MySensors nodes for the more custom or complicated applications. So far I have had no problems, actually am surprised at how reliable and fast it is. I have tried to limit the number of different vendors as I understand that can present a problem. I opted to use ZHA (Home Assistant) instead of MQTT, so far works great. Using Sonoff USB 3.0, all other Sonoff zigbee nodes, Sengled bulbs, and Aqara cube, vibration & water detectors. If I run into any problems will also post here.

      [Using Home Assistant, Intel NUC, Zwave, MySensors 2.4 & 915, Zigbee, ESP]

      posted in General Discussion
      novicit
      novicit
    • RE: 110v-230v AC to Mysensors PCB board

      @Brijesh-Mishra , I see two issues with your photos. 1) the 3.3V regulator is on backwards. If you earlier in this thread someone comments that the regulator needs to be put on backward. The white design on the board is not correct. That was also my experience with the boards I built. The flat side of the regulator should face the two cap's. 2) more importantly, it appears that you used a thermal fuse in the spot where fuse #1 goes. Fuse #1 is supposed to be a 300ma slo blow fuse. If that is what you have there no problem, but it looks like the thermal discussed in the thread. This board does not have a place for the thermal fuse. I would consider this a serious safety issue, but I am not an expert. Hope this helps.

      posted in Hardware
      novicit
      novicit
    • RE: "Error sending switch command, check device/hardware !"

      @sama, I had similar problems, always with relay nodes. The solution that has worked 100% of the time for me is to add a delay(100) as described by @kk02067 at the end of the forum thread of the same name:
      https://forum.mysensors.org/topic/4987/error-sending-switch-command-check-device-hardware
      Don't know if this will solve your problem, but worth a try.

      posted in Troubleshooting
      novicit
      novicit
    • Logging debug messages over long periods

      This post describes a method I utilize for logging of long term debug messages. Hopefully it will help others. It is not as useful or elegant as the battery powered sd-card module @sundberg84 is looking at, but it works for my purposes.

      I have a @ceech solar board with sensors for temp/hum (HTU21DF), barometer (BMP180), light sensor (BH1750), and a lightning sensor (AS3935). The board is great, all the code works fine. But on a random basis the node will freeze, sometimes in 8 hrs, sometimes 5 days, completely random it appears. So I needed to put debug statements in the code, and find a way to log the debug messages over a period of at least a week. The node wakes every 1 minute to check Baro for weather forecasting, and every 4 mins for all the sensors to report. Additionally, it wakes on interrupt from the lightning sensor. This board is destined to be set up outside powered by a small solar panel, and an 18650 battery. So this has to be solved before sealing it up and mounting in the yard somewhere.

      I have a Raspberry PI 2 sitting around so I decided to use it to do the logging. It is connected via a USB port to an FTDI serial module, which in turn is connected to the solar board tx/rx pins. For software, I found a Python program called ‘grabserial’ (github.com/tbird20d/grabserial) which will take serial input from the USB port and write it to a log file.

      The Pi is operating in a headless mode, connected via WiFi. So I can put the Pi and solar board anywhere out of the way as long as there is an outlet to power the Pi. I log in via SSH to the Pi.

      Using ’grabserial’ requires running the program in background and also to keep it running after I log off the the pi. The command I use is:
      nohup ~/grabserial -d /dev/ttyUSB0 -T -o ceechlog -Q &

      where:
      nohup => allows the program to continue running (not hangup) when I log off the Pi.
      -d => The device to listen on. To get which USB port, I ran ls /dev/tty* which lists all devices. Just look for your USB in the list.
      -T => Puts a system time stamp on each line of logged data. Valuable!
      -o => Tells grabserial the file to output the logging to. In this case I called it ceechlog.
      -Q => Instructs grabserial to operate in quiet mode, i.e., don’t copy logging to the terminal.
      & => Starts the program running in background.

      To confirm the program is running in background, I use ps -A, then look for ‘grabserial’, and its process id. To stop it, just use kill xxxxx, where x is the process id. (I am a linux amateur, I am sure there are cleaner commands, but works for me.)

      For the debug statements, In each sketch function, I put Serial.print statements with a number. For example:

      void sendTempHum(void)
      {
      Serial.print(" 9”); //HERE
      float humidity = htu.readHumidity();
      send(humidityMsg.set(humidity, 0));

      Serial.print(" 10"); //HERE
      float temperatureHTU = htu.readTemperature();
      send(temperatureMsg.set(temperatureHTU, 1));
      Serial.println(" 11"); //HERE
      }
      }

      Note that the debug statements in an individual function will print on a single line in the output. The function example above will look like:
      9 10 11 The last ‘serial.print in a function is actually a serial.println to get a carriage return. This makes reading the log easier. Don’t forget to a put a blank space before each number so as to separate the #’s on each line. Of course each different function being debugged gets different numbers in the serial.print statements.

      Every few days I log in and erase the ceechlog file as it can get quite large. This kills the ‘grabserial’ process, so I just start it up again with the command above. This is not necessary though. It is just housekeeping.

      My sketch had 39 different serial.print() statements which track the progress of the program as it executes. After setting this up, my first ‘random’ freeze actually caught the exact line which caused the freeze. I had put serial.print statements on both sides of the offending line.

      Hope this is helpful to others trying to find a difficult debug issue.

      posted in Troubleshooting
      novicit
      novicit
    • RE: Simple door sensor battery node drains 2 x AA in a week due to pin D2

      To close this post out, @bjacobse was correct. After cutting the trace to the IRQ pin of the radio there is no more drain on the D2 pin. Even though the pin was not used by MySensors, the radio apparently still drained current.

      Thank You!

      posted in Troubleshooting
      novicit
      novicit
    • RE: Error sending switch command, check device/hardware !

      Update. Please note that when @kk02067 gave the response directly above it was for Ver 2.0 and referenced a line in that code. It appears that changes leading to Ver 2.1.1 the location has changed and the delay(100) line would not be added at L463 as referenced. In Ver 2.1.1 it is now added between L659 and L660. It will look like this I believe:

      L658 _msgTmp.destination = sender;
      L659 // send ACK, use transportSendRoute since ACK reply is not internal, i.e. if !transportOK do not reply
      ADD delay(100) here!!
      L660 (void)transportSendRoute(_msgTmp);

      Also, I have not yet used Ver 2.1.1, so don't know if the changes in the latest version might solve the Domoticz relay ack issue I had. This solution solved my problems 100% in Ver 2.0.

      posted in Domoticz
      novicit
      novicit
    • RE: Packet 'freezes' WiFi Gateway ESP8266

      @kr0815 Sorry for not getting back to you sooner. No, I have not come up with a solution for this. Basically I spent much of my free time for a week investigating and working to solve it - within my level of skills - but was unable to isolate the problem. I hope to get back to it when more time allows.

      I have seen another forum thread (perhaps yours) that had many of the same problem characteristics as mine. In that thread @hek was involved. Between @hed and @yveaux, that is a lot of talent. The problem is having the problem be repeatable at another installation so it can be identified. In the meantime I installed my standard wired ethernet gateway and have had no problems.

      posted in Troubleshooting
      novicit
      novicit
    • RE: How to compile MySensors on Platformio for Blue Pill

      @CarloMagno I have now compiled 2 small test programs, using RogerClarks core. I was very surprised as both used most of the Blue Pill Flash and Memory for very small sketchs.

      1. test sketch simple relay off/on used 48k (73%) of flash and 5k (24%) of memory.
      2. Sketch with simple LED off/on with 'receive' from controller and rfm69 use 58k flash (88%) and 5.2k (25%) of memory.

      I used MySensors current release, & latest Arduino IDE. Have you had similar results in the work you are doing? This would take away the Blue Pill advantage of twice the flash of a pro mini, and make it unusable.

      I will dig deeper, and try the @KooLru code above to see if it makes a difference. @monte states that it might not have functionality, but I am not sure what that means as 'core' work is beyond my skill level.

      Again, I will assume I am doing something incorrectly as I know others on MySensors forum have used the blue pill.

      posted in Troubleshooting
      novicit
      novicit
    • RE: Simple door sensor battery node drains 2 x AA in a week due to pin D2

      @bjacobse Thank you for your comment. I should have looked at that but it has been ~6 years since I paid attention to basic radio connections. 😞 I am using the MYS11 board from www.sa2avr.se and the schematic shows D2 connected to the IRQ pin of the radio. That could be it. I will test it out.

      The "connecting the radio" page of MySensors states: "The IRQ pin is only required to be connected if the MY_RX_MESSAGE_BUFFER_FEATURE is defined in the sketch. I am not using that feature for this node so I might be able to fix it by cutting a trace.

      I post my results after testing. Again, great input! Thanks.

      posted in Troubleshooting
      novicit
      novicit