Navigation

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

    joaoabs

    @joaoabs

    18
    Reputation
    97
    Posts
    987
    Profile views
    0
    Followers
    0
    Following
    Joined Last Online
    Location Portugal

    joaoabs Follow

    Best posts made by joaoabs

    • RPI GW - Including build flags somewhere for future reference

      Hi,

      During my intense troubleshooting with my RPI GW I had to recompile MySensors GW code dozens of times.
      There were some points where I didn't know what build options I had at that moment, so I had to rebuild again just to be sure.

      My suggestion for feature would be to include the build flags defined somewhere so the user could remember what was defined by the compilation time. This could be either pasted as a comment in the mysensors.conf file or a printout when a special flag is indicated.

      Something like:

      $sudo ./bin/mysgw
      Usage: mysgw [options]
      
      Options:
        -c, --config-file          Config file. [/etc/mysensors.conf]
        -h, --help                 Display a short summary of all program options.
        -q, --quiet                Quiet mode, disable log messages written to the terminal.
        --daemon                   Run as a daemon.
        --gen-soft-hmac-key        Generate and print a soft hmac key.
        --gen-soft-serial-key      Generate and print a soft serial key.
        --gen-aes-key              Generate and print an aes encryption key.
        --compiled-flags           Displays a short summary of the compiling flags when this binary was created
      $
      $sudo ./bin/mysgw --complied-options
      My Sensors GW for RPI compiled at 2020-12-02 with the following flags:
      --my-gateway=mqtt 
      --my-controller-ip-address=192.168.2.180 
      --my-mqtt-publish-topic-prefix=mysensors-out 
      --my-mqtt-subscribe-topic-prefix=mysensors-in 
      --my-mqtt-client-id=MySensorsGW 
      --my-transport=rfm69 
      --my-signing=software 
      --my-signing-request-signatures 
      --my-rfm69-frequency=433 
      --my-is-rfm69hw 
      --my-signing-debug 
      --my-rfm69-encryption-enabled 
      --my-mqtt-user=mysensorsuser 
      --my-mqtt-password=mysensorspassword
      (Other options were default. Consult documentation for further information)
      
      

      What do you think? Would it be useful? This could also be useful for OrangePI or any other *nix system.

      posted in Feature Requests
      joaoabs
      joaoabs
    • RE: πŸ’¬ Air Humidity Sensor - DHT

      For the ones looking for a library that makes this DHT sketch work, mysensors have compiled a set of libraries that include this DHT.h and many others. Just go to https://www.mysensors.org/about/arduino#optional---install-external-mysensors-examples (yes, the name is not intuitive, maybe the keyword library would make it more obvious?), or jump directly to here and follow the standard library instructions. It took me two hours to find this, hope it saves time for future followers of mysensors like myself.

      Good luck!

      posted in Announcements
      joaoabs
      joaoabs
    • RE: [Solved] RFM69 and RaspberryPI GW

      Well, one of the problems when buying from china is that it takes so long to get the stuff that we sometimes forgot what we ordered πŸ™‚

      It seems my RFM69's are in fact RFM69HW (eventhough the chip has a "H").

      After reconfiguring the sensebender code and the raspberry configure command accordingly I got dialogue between them!

      Will now try encryption 😎

      Update: It seems it's not as simple as just adding the "#define MY_RFM69_ENABLE_ENCRYPTION" in the arduino code and "#define MY_RFM69_ENABLE_ENCRYPTION" in the ./configure command for the RPI GW... Will try to sort it out and if not able to make it work, will open a different thread.

      Update2: It seems it really is after all. Just needed a reboot, and the signing personalization will be re-used πŸ™‚

      posted in Troubleshooting
      joaoabs
      joaoabs
    • RE: [solved] Rebuilding a RPI GW - What do I need to get signing working again?

      Hi,

      Got it working!
      It was a strange mix of RFM69/RFM69HW devices (all soldered into the nrf2rfm69 board - so couldn't tell which type it was) and also a faulty RFM69. Also, it seems the signing consumes much processing power (and memory) to the little at328 chips. A sketch with more than 65% memory usage may fail some signatures, so not recommended to put many functionalities in the same node, specially when running my_debug.
      Simple sketches just with a sht21 sensor are working fine with signing and RFM69 encryption.

      Copying the correct HMAC, soft-serial and AES to the mysensors.conf file and with RPI reboots after each config/make/makeinstall cycle solved the problem.

      Thanks,
      Joaoabs

      posted in Troubleshooting
      joaoabs
      joaoabs
    • RE: Can't receive parent answer

      @frits I think you are right!

      I admit initially I didn't thought it could be that because I have a slim node working 100%, but after your comment, I checked it and there is in fact a shunt between INT0 and DIO0 (I must have done it last year or so and didn't remember). The other nodes I've been trying don't have it, so that's likely the case.

      Maybe the slim node page could have some reference to this?

      I'll solder some shunts and will re-try this evening, but I'm sure that was the problem.

      My slim nodes PCB's are red, but were ordered in 2018. Not sure what PCB release they are, though.

      Thank you very much!

      posted in Troubleshooting
      joaoabs
      joaoabs
    • RE: [Solved] How to check RFM69 is a HW model ?

      Hi,

      By the PCB silk I was wrongly thinking that the module could be on of "RFM69" or "RFM69H" or "RFM69W" and "RFM69HW".

      Now if I understood correctly the diagram, the module can only be either the "RFM69W" (low power 13dBm) or the "RFM69HW" (high power 20dBm).

      Since this module has the "H" marked it should be "RFM69HW" and that is confirmed by the other side of it, because it has the two additional black ICs.

      Thanks!

      rfm69-2.jpg

      posted in Hardware
      joaoabs
      joaoabs
    • RE: πŸ’¬ My Slim 2AA Battery Node

      Hello,

      I'm sorry to insist on this one, but I'm a bit lost....

      I could understand that the recommended bootloader is MiniCore. I installed it in my Arduino IDE and after several tries-and-errors I believe I was able to burn the MiniCore bootloader by using an USBasp2 connected to the ICSP on the slim board:

      /home/jabss/Desktop/arduino-1.8.2/hardware/tools/avr/bin/avrdude -C/root/.arduino15/packages/MiniCore/hardware/avr/2.0.1/avrdude.conf -v -patmega328p -cusbasp -Pusb -e -Ulock:w:0x3f:m -Uefuse:w:0xff:m -Uhfuse:w:0xd7:m -Ulfuse:w:0xe2:m 
      
      avrdude: Version 6.3, compiled on Jan 17 2017 at 11:00:16
               Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
               Copyright (c) 2007-2014 Joerg Wunsch
      
               System wide configuration file is "/root/.arduino15/packages/MiniCore/hardware/avr/2.0.1/avrdude.conf"
               User configuration file is "/home/jabss/.avrduderc"
               User configuration file does not exist or is not a regular file, skipping
      
               Using Port                    : usb
               Using Programmer              : usbasp
               AVR Part                      : ATmega328P
               Chip Erase delay              : 9000 us
               PAGEL                         : PD7
               BS2                           : PC2
               RESET disposition             : dedicated
               RETRY pulse                   : SCK
               serial program mode           : yes
               parallel program mode         : yes
               Timeout                       : 200
               StabDelay                     : 100
               CmdexeDelay                   : 25
               SyncLoops                     : 32
               ByteDelay                     : 0
               PollIndex                     : 3
               PollValue                     : 0x53
               Memory Detail                 :
      
                                        Block Poll               Page                       Polled
                 Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
                 ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
                 eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
                 flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
                 lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                 hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                 efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                 lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                 calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
                 signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
      
               Programmer Type : usbasp
               Description     : USBasp, http://www.fischl.de/usbasp/
      
      avrdude: auto set sck period (because given equals null)
      avrdude: AVR device initialized and ready to accept instructions
      
      Reading | ################################################## | 100% 0.00s
      
      avrdude: Device signature = 0x1e950f (probably m328p)
      avrdude: erasing chip
      avrdude: auto set sck period (because given equals null)
      avrdude: reading input file "0x3f"
      avrdude: writing lock (1 bytes):
      
      /home/jabss/Desktop/arduino-1.8.2/hardware/tools/avr/bin/avrdude -C/root/.arduino15/packages/MiniCore/hardware/avr/2.0.1/avrdude.conf -v -patmega328p -cusbasp -Pusb -Uflash:w:/root/.arduino15/packages/MiniCore/hardware/avr/2.0.1/bootloaders/empty/empty.hex:i -Ulock:w:0x0f:m 
      
      avrdude: Version 6.3, compiled on Jan 17 2017 at 11:00:16
               Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
               Copyright (c) 2007-2014 Joerg Wunsch
      
               System wide configuration file is "/root/.arduino15/packages/MiniCore/hardware/avr/2.0.1/avrdude.conf"
               User configuration file is "/home/jabss/.avrduderc"
               User configuration file does not exist or is not a regular file, skipping
      
               Using Port                    : usb
               Using Programmer              : usbasp
               AVR Part                      : ATmega328P
               Chip Erase delay              : 9000 us
               PAGEL                         : PD7
               BS2                           : PC2
               RESET disposition             : dedicated
               RETRY pulse                   : SCK
               serial program mode           : yes
               parallel program mode         : yes
               Timeout                       : 200
               StabDelay                     : 100
               CmdexeDelay                   : 25
               SyncLoops                     : 32
               ByteDelay                     : 0
               PollIndex                     : 3
               PollValue                     : 0x53
               Memory Detail                 :
      
                                        Block Poll               Page                       Polled
                 Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
                 ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
                 eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
                 flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
                 lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                 hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                 efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                 lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                 calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
                 signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
      
               Programmer Type : usbasp
               Description     : USBasp, http://www.fischl.de/usbasp/
      
      avrdude: auto set sck period (because given equals null)
      Writing | ################################################## | 100% 0.00s
      
      avrdude: 1 bytes of lock written
      avrdude: verifying lock memory against 0x3f:
      avrdude: load data lock data from input file 0x3f:
      avrdude: input file 0x3f contains 1 bytes
      avrdude: reading on-chip lock data:
      
      Reading | ################################################## | 100% 0.00s
      
      avrdude: verifying ...
      avrdude: 1 bytes of lock verified
      avrdude: reading input file "0xff"
      avrdude: writing efuse (1 bytes):
      
      Writing | ################################################## | 100% 0.00s
      
      avrdude: 1 bytes of efuse written
      avrdude: verifying efuse memory against 0xff:
      avrdude: load data efuse data from input file 0xff:
      avrdude: input file 0xff contains 1 bytes
      avrdude: reading on-chip efuse data:
      
      Reading | ################################################## | 100% 0.00s
      
      avrdude: verifying ...
      avrdude: 1 bytes of efuse verified
      avrdude: reading input file "0xd7"
      avrdude: writing hfuse (1 bytes):
      
      Writing | ################################################## | 100% 0.01s
      
      avrdude: 1 bytes of hfuse written
      avrdude: verifying hfuse memory against 0xd7:
      avrdude: load data hfuse data from input file 0xd7:
      avrdude: input file 0xd7 contains 1 bytes
      avrdude: reading on-chip hfuse data:
      
      Reading | ################################################## | 100% 0.00s
      
      avrdude: verifying ...
      avrdude: 1 bytes of hfuse verified
      avrdude: reading input file "0xe2"
      avrdude: writing lfuse (1 bytes):
      
      Writing | ################################################## | 100% 0.00s
      
      avrdude: 1 bytes of lfuse written
      avrdude: verifying lfuse memory against 0xe2:
      avrdude: load data lfuse data from input file 0xe2:
      avrdude: input file 0xe2 contains 1 bytes
      avrdude: reading on-chip lfuse data:
      
      Reading | ################################################## | 100% 0.00s
      
      avrdude: verifying ...
      avrdude: 1 bytes of lfuse verified
      
      avrdude done.  Thank you.
      
      avrdude: AVR device initialized and ready to accept instructions
      
      Reading | ################################################## | 100% 0.00s
      
      avrdude: Device signature = 0x1e950f (probably m328p)
      avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
               To disable this feature, specify the -D option.
      avrdude: erasing chip
      avrdude: auto set sck period (because given equals null)
      avrdude: reading input file "/root/.arduino15/packages/MiniCore/hardware/avr/2.0.1/bootloaders/empty/empty.hex"
      avrdude: writing flash (2 bytes):
      
      Writing | ################################################## | 100% 0.07s
      
      avrdude: 2 bytes of flash written
      avrdude: verifying flash memory against /root/.arduino15/packages/MiniCore/hardware/avr/2.0.1/bootloaders/empty/empty.hex:
      avrdude: load data flash data from input file /root/.arduino15/packages/MiniCore/hardware/avr/2.0.1/bootloaders/empty/empty.hex:
      avrdude: input file /root/.arduino15/packages/MiniCore/hardware/avr/2.0.1/bootloaders/empty/empty.hex contains 2 bytes
      avrdude: reading on-chip flash data:
      
      Reading | ################################################## | 100% 0.04s
      
      avrdude: verifying ...
      avrdude: 2 bytes of flash verified
      avrdude: reading input file "0x0f"
      avrdude: writing lock (1 bytes):
      
      Writing | ################################################## | 100% 0.01s
      
      avrdude: 1 bytes of lock written
      avrdude: verifying lock memory against 0x0f:
      avrdude: load data lock data from input file 0x0f:
      avrdude: input file 0x0f contains 1 bytes
      avrdude: reading on-chip lock data:
      
      Reading | ################################################## | 100% 0.00s
      
      avrdude: verifying ...
      avrdude: 1 bytes of lock verified
      
      avrdude done.  Thank you.
      
      

      Just for reference, the parameters were:
      Board: Atmega328
      Bootloader: No (only worked this way, but still not sure what this means: If is already a bootloader on the chip, or if we want to write a bootloader)
      Variant: 328P
      BOD: Disabled
      Clock: 8Mhz internal (here I think its what we want to configure on the target chip - I wasn't sure what was about because it could also have been the clock frequency of the programmer)
      Compiler LTO: Disabled
      Programer: USBASP

      Anyway, after this supposed success message, I believe I have a MiniCore bootloader in the chip and now it should be able to be programed with the AVRISPMKII (with the usb/serial programing adapter I use to program my mini-pros).

      However, I'm not able to get it working. Maybe I'm choosing the wrong definitions in the arduino IDE.
      As board definition, I'm using the same as when burning the bootloader:

      Board: Atmega328 (from the minicore subset)
      Bootloader: Yes
      Variant: 328P
      BOD: Disabled
      Clock: 8Mhz internal
      Compiler LTO: Disabled
      Programer: AVRISPMKII

      For instance, to load the ascii table example (for testing purposes), I get this error:

      Insert Code Build options changed, rebuilding all
      Sketch uses 2330 bytes (7%) of program storage space. Maximum is 32256 bytes.
      Global variables use 308 bytes (15%) of dynamic memory, leaving 1740 bytes for local variables. Maximum is 2048 bytes.
      /home/jabss/Desktop/arduino-1.8.2/hardware/tools/avr/bin/avrdude -C/root/.arduino15/packages/MiniCore/hardware/avr/2.0.1/avrdude.conf -v -patmega328p -carduino -P/dev/ttyUSB0 -b38400 -D -Uflash:w:/tmp/arduino_build_636369/ASCIITable.ino.hex:i 
      
      avrdude: Version 6.3, compiled on Jan 17 2017 at 11:00:16
               Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
               Copyright (c) 2007-2014 Joerg Wunsch
      
               System wide configuration file is "/root/.arduino15/packages/MiniCore/hardware/avr/2.0.1/avrdude.conf"
               User configuration file is "/home/jabss/.avrduderc"
               User configuration file does not exist or is not a regular file, skipping
      
               Using Port                    : /dev/ttyUSB0
               Using Programmer              : arduino
               Overriding Baud Rate          : 38400
      avrdude: stk500_recv(): programmer is not responding
      avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
      avrdude: stk500_recv(): programmer is not responding
      avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
      avrdude: stk500_recv(): programmer is not responding
      avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
      avrdude: stk500_recv(): programmer is not responding
      avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
      avrdude: stk500_recv(): programmer is not responding
      avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
      avrdude: stk500_recv(): programmer is not responding
      avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
      avrdude: stk500_recv(): programmer is not responding
      avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
      avrdude: stk500_recv(): programmer is not responding
      avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
      avrdude: stk500_recv(): programmer is not responding
      avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
      avrdude: stk500_recv(): programmer is not responding
      avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
      
      avrdude done.  Thank you.
      
      Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.
      

      Any hint on what I may be doing wrong?
      Thanks,

      posted in OpenHardware.io
      joaoabs
      joaoabs
    • RE: OpenHAB 2.5 MySensors Serial Gateway - How to install

      Hi,

      The mysgw seems to be creating a link to the wrong TTY.
      When I connect the arduino gateway, I get the /dev/ttyUSB1 device.

      Insert Code Herepi@nettemp:~/MySensors $ ls /dev/tty*
      /dev/tty    /dev/tty15  /dev/tty22  /dev/tty3   /dev/tty37  /dev/tty44  /dev/tty51  /dev/tty59  /dev/tty9
      /dev/tty0   /dev/tty16  /dev/tty23  /dev/tty30  /dev/tty38  /dev/tty45  /dev/tty52  /dev/tty6   /dev/ttyAMA0
      /dev/tty1   /dev/tty17  /dev/tty24  /dev/tty31  /dev/tty39  /dev/tty46  /dev/tty53  /dev/tty60  /dev/ttyUSB0
      /dev/tty10  /dev/tty18  /dev/tty25  /dev/tty32  /dev/tty4   /dev/tty47  /dev/tty54  /dev/tty61  /dev/ttyUSB1
      /dev/tty11  /dev/tty19  /dev/tty26  /dev/tty33  /dev/tty40  /dev/tty48  /dev/tty55  /dev/tty62  /dev/ttyprintk
      /dev/tty12  /dev/tty2   /dev/tty27  /dev/tty34  /dev/tty41  /dev/tty49  /dev/tty56  /dev/tty63
      /dev/tty13  /dev/tty20  /dev/tty28  /dev/tty35  /dev/tty42  /dev/tty5   /dev/tty57  /dev/tty7
      /dev/tty14  /dev/tty21  /dev/tty29  /dev/tty36  /dev/tty43  /dev/tty50  /dev/tty58  /dev/tty8
      
      

      Then I start the mysgw and a new tty is created: "/dev/ttyMySensorsGateway", which looks nice. However, the mysgw returns lots of errors:

      mysgw: Starting gateway...
      mysgw: Protocol version - 2.2.0
      mysgw: Serial port /dev/ttyMySensorsGateway (115200 baud) created
      mysgw: MCO:BGN:INIT GW,CP=RNNGL---,VER=2.2.0
      mysgw: TSF:LRT:OK
      mysgw: TSM:INIT
      mysgw: TSF:WUR:MS=0
      mysgw: !TSM:INIT:TSP FAIL
      mysgw: TSM:FAIL:CNT=1
      mysgw: TSM:FAIL:DIS
      mysgw: TSF:TDI:TSL
      mysgw: TSM:INIT
      mysgw: !TSM:INIT:TSP FAIL
      mysgw: TSM:FAIL:CNT=2
      mysgw: TSM:FAIL:DIS
      mysgw: TSF:TDI:TSL
      

      Then I go check what is wrong an I see the pointer wasn't created towards "/dev/ttyUSB1", but "/dev/pts/1":

      pi@nettemp:~/MySensors $ ls -larth /dev/ttyMySensorsGateway 
      lrwxrwxrwx 1 root root 10 Apr 26 18:27 /dev/ttyMySensorsGateway -> /dev/pts/1
      

      Taking a look into the /dev/ttyUSB1 directly I can see it is fine, the problem is the GW software on the Raspberry PI that is pointing towards the wrong tty:

      pi@nettemp:~ $ stty -F /dev/ttyUSB1 cs8 115200 ignbrk -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke noflsh -ixon -crtscts
      pi@nettemp:~ $ cat /dev/ttyUSB1 
      0;255;3;0;9;0 MCO:BGN:INIT GW,CP=RNNGAS--,VER=2.2.0
      0;255;3;0;9;0;255;3;0;9;0 MCO:BGN:INIT GW,CP=RNNGAS--,VER=2.2.0
      0;255;3;0;9;26 SGN:PER:OK
      0;255;3;0;9;64 SGN:INI:BND OK
      0;255;3;0;9;67 TSM:INIT
      0;255;3;0;9;69 TSF:WUR:MS=0
      0;255;3;0;9;77 TSM:INIT:TSP OK
      0;255;3;0;9;79 TSM:INIT:GW MODE
      0;255;3;0;9;82 TSM:READY:ID=0,PAR=0,DIS=0
      0;255;3;0;9;87 MCO:REG:NOT NEEDED
      0;255;3;0;14;Gateway startup complete.
      0;255;0;0;18;2.2.0
      0;255;3;0;9;91 MCO:BGN:STP
      0;255;3;0;9;98 MCO:BGN:INIT OK,TSP=1
      

      Any idea of how to make this work?

      Where can I see the alternatives for the "
      ./configure --my-gateway=serial --my-serial-is-pty --my-serial-pty=/dev/ttyMySensorsGateway --my-rf24-channel=69 --my-transport=nrf24 --my-serial-groupname=tty --my-config-file=/etc/mysensors.dat" command?

      Thanks,

      posted in OpenHAB
      joaoabs
      joaoabs
    • RE: SW_Signing failing: !TSF:MSG:SIGN FAIL

      Hello,

      The GW sketch is the simplest possible. It is the SerialGateway.ino example just with the added flags for the signing.
      It seems to have enough resources

      Sketch uses 21440 bytes (66%) of program storage space. Maximum is 32256 bytes.
      Global variables use 1401 bytes (68%) of dynamic memory, leaving 647 bytes for local variables. Maximum is 2048 bytes.
      

      The node sketch is the Relay example sketch, where I then added, one by one, the code from other examples such as Door/Win/Button (tripwire), Temperature (DS18B20), Temp/Hum (DHT22) and Motion (HC-SR501).

      I have a pretty basic version control, so for each new sensor type I was adding I was just creating another file. Since all the signature process was done (and written in the eeprom), I went back to the basics (sketch with Relay + Door) with the signing flags enabled and could confirm it worked with signatures (so it must be something I added). I then went version-by-version, enabling the flags and confirmed it was still working as I was progressing.
      I've now reached a point where I just have the last sensor to add (Motion HC-SR501) but the available memory is concerning:

      Build options changed, rebuilding all
      Sketch uses 28030 bytes (91%) of program storage space. Maximum is 30720 bytes.
      Global variables use 1542 bytes (75%) of dynamic memory, leaving 506 bytes for local variables. Maximum is 2048 bytes.
      Low memory available, stability problems may occur.
      
      

      I'll leave as it is, (disabling the signing debug, the memory use drops to 71%). Just out of curiosity, I checked the memory use on the original node sketch (without signing debug) and it was 73%.

      Still not sure if it was an issue related with the memory or with the additional code I added for the Motion Sensor.
      However, the strange conclusion is that it was really on the node, and not on the gateway as we thought.

      I'll leave it on during the night in order to see if it hangs or something.

      Thanks for your help!
      Joaoabs

      posted in Troubleshooting
      joaoabs
      joaoabs
    • RE: πŸ’¬ AC-DC double solid state relay module

      Hi,
      Any particular reason for the values of the thermal cut-offs? (73ΒΊC, 10A)?
      This temperature (73ΒΊC) makes it difficult to solder, I've burned a couple when trying to solder it... And why 10A? Shouldn't we get a lower current? I know the other fuse is limiting the current to 0.2A, but if we have a lower current on this one we may get cheaper components... Wouldn't this one, for instance, do the same function? https://www.ebay.com/itm/10-Pcs-Fuji-Microtemp-Thermal-Fuse-115-TF-Cutoff-1A-250V-New/322657006381

      If the PCB is inside a box, without any lossen wires, couldn't we limit the temperature to a sliglhly higher value (115ΒΊC)?

      Thanks

      posted in OpenHardware.io
      joaoabs
      joaoabs

    Latest posts made by joaoabs

    • RE: Is MySensors RPI GW 32bit only?

      @joaoabs Got it. It doesn't compile if we don't replace the RFM69_MAX_PACKET_LEN (0x40ul) πŸ™‚

      And I can confirm that the procedure above worked. Compiled directly in a RPI4 with 64bit OS.

      pi@raspberrypi:~ $ file /usr/local/bin/mysgw
      /usr/local/bin/mysgw: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=beb479db20a0f93b0fc004832e06c8213d779bb6, for GNU/Linux 3.7.0, with debug_info, not stripped
      
      
      posted in Troubleshooting
      joaoabs
      joaoabs
    • RE: Is MySensors RPI GW 32bit only?

      @Dragos-Pascale said in Is MySensors RPI GW 32bit only?:

      in hal/transport/RFM69/driver/new/RFM69_new.h you must also replace
      #define RFM69_MAX_PACKET_LEN (0x40u) with
      #define RFM69_MAX_PACKET_LEN (0x40ul)
      if you are using RFM69 radio

      @Dragos-Pascale Why that change? What is the behavior if you don't do it?

      posted in Troubleshooting
      joaoabs
      joaoabs
    • RE: πŸ’¬ Relay

      Hi,
      Trying to go deep on the API and come this this doubt: The second example (with button) the child seems to be declared as "S_LIGHT" and the receiving messages are "V_LIGHT", while the first example seems better suitable for a relay (child as "S_BINNARY" and requests as "V_STATUS").
      I haven't found any "S_LIGHT" or "V_LIGHT" in the API, only "S_LIGHT_LEVEL" and "V_LIGHT_LEVEL". What is the most suitable type for a relay node with a local button?

      posted in Announcements
      joaoabs
      joaoabs
    • RE: [Solved] How to check RFM69 is a HW model ?

      Hi,

      By the PCB silk I was wrongly thinking that the module could be on of "RFM69" or "RFM69H" or "RFM69W" and "RFM69HW".

      Now if I understood correctly the diagram, the module can only be either the "RFM69W" (low power 13dBm) or the "RFM69HW" (high power 20dBm).

      Since this module has the "H" marked it should be "RFM69HW" and that is confirmed by the other side of it, because it has the two additional black ICs.

      Thanks!

      rfm69-2.jpg

      posted in Hardware
      joaoabs
      joaoabs
    • RE: [Solved] How to check RFM69 is a HW model ?

      Resuscitating this old post...

      Not sure which type is my RFM69.

      It isn't marked as "RFM69HW" neither simply as "RFM69". It seems it is a "RFM69H" (no W).

      Is there any flag like "MY_IS_RFM69H" (without "W") ? πŸ˜€

      What should I use for this one? I'm getting erratic behavior in both flag options (with "MY_IS_RFM69HW")....

      rfm69.jpg

      posted in Hardware
      joaoabs
      joaoabs
    • Is it possible to request sensor status (via MQTT)?

      Hi,

      I'm testing a dual-SSR node connected to 220v (therefore, never sleeping).
      The node data is the following:

      Node ID: 80
      Childs:
      * HTU21 TEMP: 20
      * HTU21 HUM: 40
      * SSR1: 10
      * SSR2: 11
      

      Following the MySensors API structure

      Node-ID   /   Child-ID   /  Command   /  Ack   / Type  / Payload
      

      I believe I'm able to set a relay via MQTT with the command line command:

      mosquitto_pub -d -h 192.168.2.180 -u myuser -P mypass -t mysensors-in/80/10/1/1/2 -m "0"
      

      and get (what I believe its the confirmation):

      pi@raspberrypi:~ $ mosquitto_sub -h 192.168.2.180 -p 1883 -u myuser -P mypass -t mysensors-out/80/# -d
      Client mosqsub|5920-raspberryp sending CONNECT
      Client mosqsub|5920-raspberryp received CONNACK (0)
      Client mosqsub|5920-raspberryp sending SUBSCRIBE (Mid: 1, Topic: mysensors-out/80/#, QoS: 0)
      Client mosqsub|5920-raspberryp received SUBACK
      Subscribed (mid: 1): 0
      
      
      Client mosqsub|5920-raspberryp received PUBLISH (d0, q0, r0, m0, 'mysensors-out/80/10/1/1/2', ... (1 bytes))
      0
      

      I don't have at the moment anything connected to the relay to confirm if its switching or not, so I was trying to use the "request" command to request the child statuses.

      Something like:

      mosquitto_pub -d -h 192.168.2.180 -u myuser -P mypass -t mysensors-in/80/10/2/1/2 -m ""
      
      

      Even trying to request temperature statuses:

      pi@raspberrypi:~/mysensors-back $ mosquitto_pub -d -h 192.168.2.180 -u myuser -P mypass -t mysensors-in/80/20/2/1/0 -m ""
      
      

      but I'm not getting anything:

      Client mosqsub|6459-raspberryp received PUBLISH (d0, q0, r0, m0, 'mysensors-out/80/20/2/1/0', ... (0 bytes))
      Client mosqsub|6459-raspberryp received PUBLISH (d0, q0, r0, m0, 'mysensors-out/80/10/2/1/2', ... (0 bytes))
      

      I've read in the API documentation that the "request" command is "usually from an actuator destined for controller" so I'm wondering if it would be just "usually" or definitely "uniquelly" 😊 . Would there be any way of "asking" the sensors their statuses (via MQTT)?

      Cheers

      posted in Troubleshooting
      joaoabs
      joaoabs
    • RE: MQTT GW with RFM69 on RPi

      @Yveaux Hello, Any update if this is an issue or just a cosmetic log thing? Cheers

      posted in Troubleshooting
      joaoabs
      joaoabs
    • Soldering a coax cable to RFM69

      Hi,

      What do you think about this?
      Wanted to increase the GW range so trying to use a bigger 433MHz antenna.
      Would this be the correct way to make it?

      alt text

      Comment/suggestions will be welcomed

      posted in My Project
      joaoabs
      joaoabs
    • Can a node request a status from other node?

      Hello,

      I'd like to have a "6 button node" that will control lights (in other nodes). Since some lights are far away (not visible), I'm thinking in putting there a led just to signal if the light is currently on or off.

      For this to happen, I guess I'll have to request the status of each light every time a button is pressed (or pool it every 10m or so).

      Is this possible? How?

      Thanks

      posted in Feature Requests
      joaoabs
      joaoabs
    • RE: πŸ’¬ My Slim 2AA Battery Node

      Hi @m26872

      Congrats for the great and simple design.
      I've been troubleshooting this slimnode with RFM69 radios and realized that a shunt between RFM69's DIO0 and Mega328's INT0 is required, otherwise the node will not "hear" the gateway. Even if the nrf2rmf69 board is used this shunt is required.
      It seems this is a re-current issue. Although this may be solved in the PCB2.0 could it be mentioned somewhere in the page above?

      Thanks and cheers!

      posted in OpenHardware.io
      joaoabs
      joaoabs