Navigation

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

    bilbolodz

    @bilbolodz

    14
    Reputation
    91
    Posts
    674
    Profile views
    0
    Followers
    1
    Following
    Joined Last Online

    bilbolodz Follow

    Best posts made by bilbolodz

    • RE: Repeatrer level limit (NRF24L01 transport)

      It looks that I've achieved my goal. I'm able dynamically change parent id node (proved in lab) and power level (don't have idea how to check it). You can send V_VAR1 message with number of preferred parent or V_VAR2 with requested power (values: 0 - RF24_PA_MIN, 1 - RF24_PA_LOW, 2 - RF24_PA_HIGH, RF24_PA_MAX) and then REBOOT node (required to changes take effect). Version of sketch reported to controller is changed dynamically depends of set power level.

      My "repeater: code bellow:

      #define SKETCH_NAME "Repeater Node L1"
      #define SV "1.0.1" 
      #define MY_RADIO_NRF24
      #define MY_REPEATER_FEATURE
      
      int8_t myParrentNodeId;
      int8_t myRF24PALevel;
      
      #define MY_PARENT_NODE_ID myParrentNodeId
      #define MY_RF24_PA_LEVEL myRF24PALevel
      
      #include <MySensors.h>
      
      #ifndef MY_REPEATER_FEATURE
      #define SKETCH_VERSION1 SV
      #else
      #define SKETCH_VERSION1 SV "R"
      #endif
      
      #define SKETCH_VERSION SKETCH_VERSION1 "   "
      
      uint8_t SketchVersion[sizeof(SKETCH_VERSION)];
      
      #define EEPROM_PARENT 0
      #define EEPROM_PA_LEVEL 1
      
      void before() {
      
        int8_t tmpui = loadState(EEPROM_PARENT);
        if (tmpui == 0xFF)
        {
          myParrentNodeId = 0;
        }
        else {
          myParrentNodeId = tmpui;
        }
      
        memcpy(SketchVersion, SKETCH_VERSION, sizeof(SKETCH_VERSION));
      
        tmpui = loadState(EEPROM_PA_LEVEL);
        switch (tmpui)
        {
          case 0:
            myRF24PALevel = RF24_PA_MIN;
            memcpy(SketchVersion + sizeof(SKETCH_VERSION) - 4, "MIN", 3);
            break;
          case 1:
            myRF24PALevel = RF24_PA_LOW;
            memcpy(SketchVersion + sizeof(SKETCH_VERSION) - 4, "LOW", 3);
            break;
          case 2:
            myRF24PALevel = RF24_PA_HIGH;
            memcpy(SketchVersion + sizeof(SKETCH_VERSION) - 4, "HIG", 3);
            break;
          case 3:
            myRF24PALevel = RF24_PA_MAX;
            memcpy(SketchVersion + sizeof(SKETCH_VERSION) - 4, "MAX", 3);
            break;
          default:
            myRF24PALevel = RF24_PA_MAX;
            break;
        }
      }
      
      void setup()
      {
      
      }
      
      void presentation()
      {
        //Send the sensor node sketch version information to the gateway
        //sendSketchInfo("Repeater Node L1 MAX", "1.0");
        sendSketchInfo(SKETCH_NAME, SketchVersion);
      }
      
      void loop()
      {
      }
      
      void receive(const MyMessage &message) {
        if (!message.isAck()) {
          if (message.type == V_VAR1) {
            uint8_t tmpui = message.getByte();
            uint8_t tmpui1 = loadState(EEPROM_PARENT);
            if (tmpui != tmpui1)
            {
              saveState(EEPROM_PARENT, tmpui);
            }
          }
          else if (message.type == V_VAR2)
          {
            uint8_t tmpui = message.getByte();
            uint8_t tmpui1 = loadState(EEPROM_PA_LEVEL);
            if (tmpui >= 0 && tmpui <= 3)
            {
              if (tmpui != tmpui1)
              {
                saveState(EEPROM_PA_LEVEL, tmpui);
              }
            }
          }
        }
      }
      
      posted in Development
      bilbolodz
      bilbolodz
    • RE: 💬 NodeManager

      It's already requested feature:

      https://github.com/mysensors/NodeManager/issues/73

      and it will be done.

      bilbolodz created this issue in mysensors/NodeManager

      closed Reversed SET/REQ logic in case of OUTPUT type sensors #73

      posted in OpenHardware.io
      bilbolodz
      bilbolodz
    • Semi static parent modification

      Some background information:

      I've bunch (over 30) nodes (NRF24) in my garden, there are working as lamp switches. I'm also using message signing. Because of RF range and required good signal quality (signing demands real stable RF network) I'm using repeaters.
      In my code I'm using:

      int8_t myParrentNodeId;
      int8_t myRF24PALelel;
      
      #define MY_PARENT_NODE_ID myParrentNodeId
      #define MY_RF24_PA_LEVEL myRF24PALelel
      

      trick to change preferred parent for nodes without needs of having different sketch image for each node and reflashing.

      Unfortunately sometimes (because of unknown reason) node changes parent node to some distant repeater node and communication with these node (over "new parent") is very poor. It's also very hard to recover node from such state (reboot command needs signing, signing needs good radio connection, radio link is poor because node is using very distant repeater).

      I've some ideas which could be implemented to remedy such situations:

      1. Possibility to BLACKLIST some repeaters - it should be a array(?) in RAM/EEPROM which contain IDs of forbidden parents

      2. Possibility to declare " MY_PARENT_NODE_IS_STATIC" but with fixed (in RAM or EEPROM) backup parrent ID. It will allow to limit possible parent to two good (in range) nodes but not break connectivity in case of primary parent failure

      3. Better RF link quality verification to be 100% sure that whole path to controller is performing well.

      4. It could be also a good idea to make possible enable/disable working node "as parent" without recompilation (easier tunning of large Mysensors network).

      posted in Feature Requests
      bilbolodz
      bilbolodz
    • Answering request command

      I'd like to build sensor which answers for "request command" with value for particular sensor. I can catch these message in
      void receive(const MyMessage &message) function but questions are:

      1. Should I answer for these message in any "special way" or just send a message with sensor value to questioning node using bool send(MyMessage &msg, bool ack) function?
      2. Is it save to use send function inside receive function or should I set flag "message to answer" and serve it "in usual way" in loop()?
      3. Could someone please clarify a bit meaning of ack parameter? Sometimes I've problems with radio connectivity and I have to find the way to inform controller (Domoticz) that "set command" send to relay was accepted and executed by sensor. Does ack solve my problems?
      posted in Development
      bilbolodz
      bilbolodz
    • RE: 💬 Battery powered glass touch switch

      OK, that's interesting data. Thanks

      posted in OpenHardware.io
      bilbolodz
      bilbolodz
    • RE: NRF24L01 SMD to DIP converter

      @mfalkvidd Yes but it's ONLY for "normal version of SMD". Versions with PA have a little different pinout.

      posted in Hardware
      bilbolodz
      bilbolodz
    • RE: Answering request command

      @Boots33 I've probably found a bug in Domoticz (beta version). In Setup page I can see that Ack in ON and timeout is 1200ms but it's NOT working (values added from default during device presentation). When I turn off and the on ACK (and save) or change timeout for any other value (and save) "ack detection" start to work (I've got an error without sensor present). Thank you for your help.

      posted in Development
      bilbolodz
      bilbolodz
    • RE: 💬 Super-capacitor-power-supply-for-wireless-sensors-w-charger

      Nice plese provide BOM because it's a little unclear which MIC5365/6 should be used

      posted in OpenHardware.io
      bilbolodz
      bilbolodz
    • RE: NRF24L01 SMD to DIP converter

      @kalina Thanks.

      At the begging quick question: are you sure that all is fine with drills? Some gerber renders in PCB factories show strange results (pcbs.io and oshpark.com).

      I've maid a quick research with comparison of cost (I've always took "the cheapest product and shipment option):

      • www.seeedstudio.com 10 pcs 4.90 USD + shipment 11.30 USD - (PCB max size 100 mm x 100m)
      • pcbs.io 4 pcs 1.50 USD + shipment free (probably problems with drills need to be checked more throughly)
      • oshpark.com 3 pcs 1.85USD + shipment free (probably problems with drills need to be checked more throughly)
      • dirtypcbs.com "protopack" (at least 10 pcs maybe more) 11.95 USD + 2 USD shipment (PCB max size 50mm x 50m, factory complaining after ZIP upload: "No board outline (.GML/.GKO/.GBR) file found")

      Of course it depends of "someone needs" but I think it could be a good idea to prepare "panelized version" with a few pcs of PCB which fits into PCB factory needs (dirtypcbs.com: 5cmx5cm, www.seeedstudio.com 10cmx10cm) for a "batch order" it should be more costs efficient.

      posted in Hardware
      bilbolodz
      bilbolodz
    • RE: 💬 FOTA (Wireless Programming)

      It's not quite clear for my how to use MYSBootloader for OTA. I'm running Domoticz as a controller (on RPI) and my gateway also is running on RPI (NRF on GPIO). Should have I one more arduino gateway connected to Windows machine running MYSController? As far I know there could be only one gateway in mysensors network.

      posted in Announcements
      bilbolodz
      bilbolodz

    Latest posts made by bilbolodz

    • RE: 💬 MDMSNode "Lighting X3" (based on ESP8266)

      First batch of devices arrived. Looks fine. I hope I will manage to install it in garden to the end of the week.

      posted in OpenHardware.io
      bilbolodz
      bilbolodz
    • RE: [security] Migrating from library version 2.1 to 2.2

      "Your code your rules" but I'm little surprised with your standpoint.

      posted in Development
      bilbolodz
      bilbolodz
    • RE: [security] Migrating from library version 2.1 to 2.2

      @anticimex OK maybe I will try but I think it could be a good idea to extend you "migration guide".

      posted in Development
      bilbolodz
      bilbolodz
    • RE: ESP8266 WiFi gateway and signing

      OK I will try it today. Yesterday I've done such procedure (without success) but now I've realised that I've used OLD (2.1) personalisation script (saved on disk) but loaded GW code compiled with 2.2 library. Probably that's an issue.

      posted in Development
      bilbolodz
      bilbolodz
    • RE: ESP8266 WiFi gateway and signing

      So I should first "personalise" ESP8266 device with "standard personalising sketch" and than upload my GW code with #define MY_SIGNING_SOFT. Right?

      posted in Development
      bilbolodz
      bilbolodz
    • RE: [security] Migrating from library version 2.1 to 2.2

      So it means that (If I want use signing) I'm stuck with mysensors version 2.1?
      I'm not able compile new code (using 2.2) and upload it over OTA because I will loose signing right (without changeing EEPROM content)?
      I think there should be a way to migrate sketch (which is using soft signing) from 2.1 to 2.2 with OTA. Secure sending of keys actually is NOT a problem because (as I understood) new in 2.2 is "only checksum" of EEPROM.
      So if I have "2.1 mysensors library" personalized devices, it's possible to write a program which gets existing data from EEPROM calculate checksum and write it to EEPROM (maybe also migrating other structures if there were other changes). Such sketch can be in safe way transferred via OTA because it doesn't contain any secret information. Then I can upload new (using 2.2 library) version of my sketch and I will have working "2.2" devices without touching it (only OTA). What do you think about it?

      Actually now I've realised (luckily) that in these "hard to get devices" I'm using hardware signing so it should be not a problem (?) 🙂

      posted in Development
      bilbolodz
      bilbolodz
    • ESP8266 WiFi gateway and signing

      Is signing for ESP8266 gateway supported? I know that hardware signing is NOT supported but how about software? If so should be personalization in usual way (using sketch from examples) like "arduino nano" nodes?

      posted in Development
      bilbolodz
      bilbolodz
    • RE: [security] Migrating from library version 2.1 to 2.2

      I've a lot devices with very hard physical access to them. I'm using OTA to change firmware so please describe how to implement "new 2.2 checksum feature" into existing sketch using OTA.

      posted in Development
      bilbolodz
      bilbolodz
    • RE: Return value of bool send(MyMessage &msg, const bool ack = false);

      @mfalkvidd said in Return value of bool send(MyMessage &msg, const bool ack = false);:

      @bilbolodz just to check: are you sure there are no repeaters or other gateways within range?

      I've to check more thoroughly but rather not.

      posted in Development
      bilbolodz
      bilbolodz
    • RE: Return value of bool send(MyMessage &msg, const bool ack = false);

      @pjr Thank you. I'm already using software ack (and message resending after timeout) for get reliable radio transport. According hardware ack:

      Hardware ack is what I get when using send(msg, true) and some other functions like present, sendSketchInfo and sendBatteryLevel
      
          Hardware ack is hop-to-hop acknowledgment
          Sending is a blocking function which returns true if an ack was received and false if ~70ms passed without receiving an hardware ack.
          Sending ack is handled automatically by the library(/radio)
          Receiving an ack is handled automatically by the library
          Re-send needs to be handled manually in each sketch (a while-loop with a counter counting up to maxRetries and using wait() between each resend seems to be the most common solution)
      

      sounds nice but above statement seems to be not true in my case: after complete node registration in GW send function returns always true even GW is powered off.... I've studied source and looks that "in the lowest level of code" send function outcome comes from: drivers/RF24/RF24.cpp function:

      LOCAL bool RF24_sendMessage(const uint8_t recipient, const void* buf, const uint8_t len)
      {
      	uint8_t RF24_status;
      	RF24_stopListening();
      	RF24_openWritingPipe( recipient );
      	RF24_DEBUG(PSTR("RF24:SND:TO=%d,LEN=%d\n"),recipient,len); // send message
      	// flush TX FIFO
      	RF24_flushTX();
      	// this command is affected in clones (e.g. Si24R1):  flipped NoACK bit when using W_TX_PAYLOAD_NO_ACK / W_TX_PAYLOAD
      	// AutoACK is disabled on the broadcasting pipe - NO_ACK prevents resending
      	RF24_spiMultiByteTransfer(recipient == BROADCAST_ADDRESS ? RF24_WRITE_TX_PAYLOAD_NO_ACK :
      	                          RF24_WRITE_TX_PAYLOAD, (uint8_t*)buf, len, false );
      	// go, TX starts after ~10us
      	RF24_ce(HIGH);
      	// timeout counter to detect HW issues
      	uint16_t timeout = 0xFFFF;
      	do {
      		RF24_status = RF24_getStatus();
      	} while  (!(RF24_status & ( _BV(RF24_MAX_RT) | _BV(RF24_TX_DS) )) && timeout--);
      	// timeout value after successful TX on 16Mhz AVR ~ 65500, i.e. msg is transmitted after ~36 loop cycles
      	RF24_ce(LOW);
      	// reset interrupts
      	RF24_setStatus(_BV(RF24_TX_DS) | _BV(RF24_MAX_RT) );
      	// Max retries exceeded
      	if(RF24_status & _BV(RF24_MAX_RT)) {
      		// flush packet
      		RF24_DEBUG(PSTR("!RF24:SND:MAX_RT\n"));	// max retries, no ACK
      		RF24_flushTX();
      	}
      	RF24_startListening();
      	// true if message sent
      	return (RF24_status & _BV(RF24_TX_DS));
      }
      

      so it's from RF24 status register. I've to check how it's working on other RF24 modules. I've read that there are some comparability problems with non original Chinese clones of NRF24L01 chipset.

      posted in Development
      bilbolodz
      bilbolodz