Navigation

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

    cvdenzen

    @cvdenzen

    9
    Reputation
    26
    Posts
    184
    Profile views
    0
    Followers
    0
    Following
    Joined Last Online

    cvdenzen Follow

    Best posts made by cvdenzen

    • RE: Use FreeRTOS?

      Yes, the pin change intgerrupt gives me what I want. The sleep call also wakes up on this interrupt, I thought it would only wake up in INT0 or INT1.

      So for now my experiments with FreeRTOS end.

      @electrik thanks for the hint!

      posted in Development
      cvdenzen
      cvdenzen
    • RE: Millis and sleep

      Finally, after reading the data sheet, I see the problem with the watchdog timer: its value can not be read.
      Timer2 would be a nice option. I will have a look at that. Thanks for your answers!

      posted in Feature Requests
      cvdenzen
      cvdenzen
    • RE: MQTT Gateway floods logfile if broker is not reachable

      @mfalkvidd The development branch has the same behavior. An edit in core/MyGatewayTransportMQTTClient.cpp (I added a "delay(3000)" after line 148 in reconnectMQTT(void)) made it a lot better!

      posted in Bug Reports
      cvdenzen
      cvdenzen
    • RE: Node doesn't receive data from RPI MQTT Gateway

      @mfalkvidd Thank you for the link. I followed the instructions, had to download/compile some packages.
      It will take some time for me, I have to solve this error:

       git commit -m "Accept wildcards in mqtt subscription prefix"
      cppcheck: Failed to load library configuration file 'std.cfg'. File not found
      cppcheck: Failed to load library configuration file 'avr'. File not found
      nofile:0:0: information: Failed to load the library avr [failedToLoadCfg]
      
      

      Few minutes later, resolved, had to add CFGDIR to make cppcheck:

      sudo make install FILESDIR=/usr/share/cppcheck CFGDIR=/usr/share/cppcheck
      
      posted in Troubleshooting
      cvdenzen
      cvdenzen
    • Sleep3 class to be used with many interrupts

      I have been struggling with the MySensors sleep method. My PIR sensor is not using one of the two supported interrupts.
      I have started writing some code, but that is just a beginning. Is anybody interested in this subject or should I just write it for my own use?
      Any help would be welcome, it is not unlikely that I am missing something important in this mechanism.
      The actual (partial) code can be found at
      https://sourceforge.net/p/easypirmultisensorsbox/code/ci/cvdenzen/tree/easyPIRmultisensorsBox2_155/easyPIRmultisensorsBox2_155/

      I named the new class Sleep3.

      Advantages of current (december 2021) sleep implementation:

      • it works
      • it is simple to use
      • there is a good description how to implement it
        Problems with current (december 2021) sleep implementation:
      • it only handles two interrupt sources
      • it captures these two interrupts, but these interrupts don't belong to the sleep mechanism
      • it only works for ATMega
      • it is not scalable to many interrupt sources
      • the return value is not safe: it is possible to miss interrupts if two interrupts happen simultaneously

      Trying to make a better sleep (class Sleep3) that improves some of the shortcomings:

      • only an interrupt service routine for the watchdog timer, the other interrupts are not of our (Sleep3) concern
      • Implement the Observer pattern
      • Use the Observer pattern to register methods that can veto a sleep call (see note 1)
      • turn off adc only once (not every iteration of sub-sleep)
      • turn off network only once (not every iteration of sub-sleep)
      • Two public methods: "sleep()" (forever), and "sleep(unsigned long sleep_time)". They return a struct
        with a few members: int errno (e.g. re-entry not allowed), bool wokeUpByWDT (if false, some other interrupt triggered wake-up),
        unsigned long requestedSleepMS, unsigned long sleepRemainingMS.
        requestedSleepMS-sleepRemainingMS can be used to adjust the millis() counter ?? it will not be accurate (can be 8 seconds off in avr).

      Note 1:
      If there is a non-processed interrupt, the cpu must not go to sleep. That happens e.g. in this scenario: the cpu is executing the loop() code and is almost at the point to call sleep(). A PIR sensor triggers an interrupt, the ISR is run, it sets a flag that is to be checked in the loop(). At that point the cpu would go to sleep. The flag would only be seen after the sleep call!
      Solution: check whether sleeping is allowed, same scenario extended with the check:
      the cpu is executing the loop() code and is almost at the point to call sleep(). A PIR sensor triggers an interrupt, the
      ISR is run in which a flag is set to be checked in the loop(). New: at that point the cpu disables interrupts, calls the
      callback methods of the observers and will be signaled by the PIR observer that it should not go to sleep(), but continue its processing. The loop is re-entered immediately and the PIR data can be sent to the gateway.

      The Observer method will be called in a locked (interrupts disabled) state just before the hardware sleep is entered.
      If the Observer notices that there is a pending interrupt on behalf of its subject, it should return false, otherwise
      it should return true (as in: allright, go to sleep).

      // The Sleep3 code that calls the observers will look like this:
      boolean sleepIsAllowed=true;
      noInterrupts();
      for (Observer observer:observers) { if (!observer()) {sleepIsAllowed=false;break}}
      if (sleepIsAllowed) {interrups();sleep;} else interrupts();
      
      // An example application looks like this:
      //
      Sleep3 sleep3; // Sleep3 is the proposed sleep class
      before() {
        sleep3.attach(sleepObserver);
        .. enable interrupts etc.
      }
      ISR (PCINT2_vect) {
        boolean PIRPinValue = digitalRead(PIR_PIN);
        queue.add(PIRPinValue);
      }
      // This method is entered with interrupts disabled
      boolean sleepObserver() {
        if (!queue.isEmpty()) return false; else return true;
      }
      void loop() {
        noInterrups(); // to lock the queue
        if (!queue.isEmpty()) {
          boolean pir=queue.remove();
          interrupts();
          // do something with pir
        } else {
          interrupts();
        }
        sleep3.sleep(SLEEP_TIME);
      }
      
      posted in Development
      cvdenzen
      cvdenzen
    • RE: MQTT Gateway floods logfile if broker is not reachable

      Looks like this was solved in branch develop at Jan, 6, 2019:
      98355b2d ( tekka 2019-01-06 18:14:10 +0100 158) delay(1000);

      posted in Bug Reports
      cvdenzen
      cvdenzen
    • RE: Node doesn't receive data from RPI MQTT Gateway

      @mfalkvidd Thank you!

      posted in Troubleshooting
      cvdenzen
      cvdenzen
    • RE: Sleep3 class to be used with many interrupts

      @Nigel31 Thank you, I will try to write some code and test it. It can take a few weeks as I have to do it in my spare time (like most of us).

      posted in Development
      cvdenzen
      cvdenzen

    Latest posts made by cvdenzen

    • RE: Sleep3 class to be used with many interrupts

      @Nigel31 Thank you, I will try to write some code and test it. It can take a few weeks as I have to do it in my spare time (like most of us).

      posted in Development
      cvdenzen
      cvdenzen
    • Sleep3 class to be used with many interrupts

      I have been struggling with the MySensors sleep method. My PIR sensor is not using one of the two supported interrupts.
      I have started writing some code, but that is just a beginning. Is anybody interested in this subject or should I just write it for my own use?
      Any help would be welcome, it is not unlikely that I am missing something important in this mechanism.
      The actual (partial) code can be found at
      https://sourceforge.net/p/easypirmultisensorsbox/code/ci/cvdenzen/tree/easyPIRmultisensorsBox2_155/easyPIRmultisensorsBox2_155/

      I named the new class Sleep3.

      Advantages of current (december 2021) sleep implementation:

      • it works
      • it is simple to use
      • there is a good description how to implement it
        Problems with current (december 2021) sleep implementation:
      • it only handles two interrupt sources
      • it captures these two interrupts, but these interrupts don't belong to the sleep mechanism
      • it only works for ATMega
      • it is not scalable to many interrupt sources
      • the return value is not safe: it is possible to miss interrupts if two interrupts happen simultaneously

      Trying to make a better sleep (class Sleep3) that improves some of the shortcomings:

      • only an interrupt service routine for the watchdog timer, the other interrupts are not of our (Sleep3) concern
      • Implement the Observer pattern
      • Use the Observer pattern to register methods that can veto a sleep call (see note 1)
      • turn off adc only once (not every iteration of sub-sleep)
      • turn off network only once (not every iteration of sub-sleep)
      • Two public methods: "sleep()" (forever), and "sleep(unsigned long sleep_time)". They return a struct
        with a few members: int errno (e.g. re-entry not allowed), bool wokeUpByWDT (if false, some other interrupt triggered wake-up),
        unsigned long requestedSleepMS, unsigned long sleepRemainingMS.
        requestedSleepMS-sleepRemainingMS can be used to adjust the millis() counter ?? it will not be accurate (can be 8 seconds off in avr).

      Note 1:
      If there is a non-processed interrupt, the cpu must not go to sleep. That happens e.g. in this scenario: the cpu is executing the loop() code and is almost at the point to call sleep(). A PIR sensor triggers an interrupt, the ISR is run, it sets a flag that is to be checked in the loop(). At that point the cpu would go to sleep. The flag would only be seen after the sleep call!
      Solution: check whether sleeping is allowed, same scenario extended with the check:
      the cpu is executing the loop() code and is almost at the point to call sleep(). A PIR sensor triggers an interrupt, the
      ISR is run in which a flag is set to be checked in the loop(). New: at that point the cpu disables interrupts, calls the
      callback methods of the observers and will be signaled by the PIR observer that it should not go to sleep(), but continue its processing. The loop is re-entered immediately and the PIR data can be sent to the gateway.

      The Observer method will be called in a locked (interrupts disabled) state just before the hardware sleep is entered.
      If the Observer notices that there is a pending interrupt on behalf of its subject, it should return false, otherwise
      it should return true (as in: allright, go to sleep).

      // The Sleep3 code that calls the observers will look like this:
      boolean sleepIsAllowed=true;
      noInterrupts();
      for (Observer observer:observers) { if (!observer()) {sleepIsAllowed=false;break}}
      if (sleepIsAllowed) {interrups();sleep;} else interrupts();
      
      // An example application looks like this:
      //
      Sleep3 sleep3; // Sleep3 is the proposed sleep class
      before() {
        sleep3.attach(sleepObserver);
        .. enable interrupts etc.
      }
      ISR (PCINT2_vect) {
        boolean PIRPinValue = digitalRead(PIR_PIN);
        queue.add(PIRPinValue);
      }
      // This method is entered with interrupts disabled
      boolean sleepObserver() {
        if (!queue.isEmpty()) return false; else return true;
      }
      void loop() {
        noInterrups(); // to lock the queue
        if (!queue.isEmpty()) {
          boolean pir=queue.remove();
          interrupts();
          // do something with pir
        } else {
          interrupts();
        }
        sleep3.sleep(SLEEP_TIME);
      }
      
      posted in Development
      cvdenzen
      cvdenzen
    • RE: Node doesn't receive data from RPI MQTT Gateway

      @mfalkvidd Thank you!

      posted in Troubleshooting
      cvdenzen
      cvdenzen
    • RE: Node doesn't receive data from RPI MQTT Gateway

      It seems like building MySensors with my edit failed but I don’t understand the error messages.
      The first error: https://ci.mysensors.org/job/MySensors/job/MySensors/job/PR-1497/2/warnings2Result/new/file.702256833/source.9006459693321295180/#1

      posted in Troubleshooting
      cvdenzen
      cvdenzen
    • RE: Node doesn't receive data from RPI MQTT Gateway

      @mfalkvidd Thank you for the link. I followed the instructions, had to download/compile some packages.
      It will take some time for me, I have to solve this error:

       git commit -m "Accept wildcards in mqtt subscription prefix"
      cppcheck: Failed to load library configuration file 'std.cfg'. File not found
      cppcheck: Failed to load library configuration file 'avr'. File not found
      nofile:0:0: information: Failed to load the library avr [failedToLoadCfg]
      
      

      Few minutes later, resolved, had to add CFGDIR to make cppcheck:

      sudo make install FILESDIR=/usr/share/cppcheck CFGDIR=/usr/share/cppcheck
      
      posted in Troubleshooting
      cvdenzen
      cvdenzen
    • RE: Node doesn't receive data from RPI MQTT Gateway

      I have made some modifications to the code, tested it and it seems to work.
      There is a pull request https://github.com/mysensors/MySensors/pull/1497 but I don't know how this will be handled by the MySensors developers.

      Can anybody give me a link or some information about the development process? A review of my code will be necessary, I am not a C programmer.

      cvdenzen created this issue in mysensors/MySensors

      open Accept wildcards in mqtt subscription prefix #1497

      posted in Troubleshooting
      cvdenzen
      cvdenzen
    • RE: Node doesn't receive data from RPI MQTT Gateway

      The problem is clear: the subscription topic that I use contains a wildcard: “+/mysensors”.
      I send my message with prefix “carl/mysensors”.
      The MySensors code assumes the length of the prefix I send is the same as the length of the subscription prefix. But it isn’t because of the wildcard character.
      Is there anybody who likes to change the code to make it work? Or should I try it myself?
      I see two possible solutions:

      1. Parse the message from end to begin and not from begin to end.
      2. Try to match the wildcard character(s) with the sent string.
      posted in Troubleshooting
      cvdenzen
      cvdenzen
    • RE: Node doesn't receive data from RPI MQTT Gateway

      @cvdenzen
      I have added a GATEWAY_DEBUG line in core/MyProtocol.cpp at line 122:

      
      	for (str = strtok_r(topic + strlen(MY_MQTT_SUBSCRIBE_TOPIC_PREFIX) + 1, "/", &p);
      	        str && index < 5;
      	        str = strtok_r(NULL, "/", &p), index++
      	    ) {
      	    GATEWAY_DEBUG(PSTR("GWT:TPS:Index=%d, mqttstr=%s\n"), str);
      

      My conclusion is that the length of the mqtt subscription topic is the problem. The first call shows that it thinks "rs" is part of the topic beyond the PREFIX. And "rs" gets translated to "0" in the outgoing mqtt message, shifting the real items one position further and dropping the last item.
      Later on I will have a look at the cause of this limitation (or maybe someone else is quicker than I am).
      The output of mysgw, first try is with topic carl/mysensors, second try (that succeeds) is with mqtt topic c/mysensors:

      Aug 15 23:53:19 DEBUG GWT:TPS:TOPIC=mysensors/all/157/255/3/0/21,MSG SENT
      Aug 15 23:53:24 DEBUG GWT:IMQ:TOPIC=carl/mysensors/157/0/1/0/3, MSG RECEIVED
      Aug 15 23:53:24 DEBUG GWT:TPS:Index=0, mqttstr=rs
      Aug 15 23:53:24 DEBUG GWT:TPS:Index=1, mqttstr=157
      Aug 15 23:53:24 DEBUG GWT:TPS:Index=2, mqttstr=0
      Aug 15 23:53:24 DEBUG GWT:TPS:Index=3, mqttstr=1
      Aug 15 23:53:24 DEBUG GWT:TPS:Index=4, mqttstr=0
      Aug 15 23:53:24 DEBUG GWT:TPS:TOPIC=mysensors/all/0/157/0/1/0,MSG SENT
      Aug 15 23:54:42 DEBUG GWT:IMQ:TOPIC=c/mysensors/157/0/1/0/3, MSG RECEIVED
      Aug 15 23:54:42 DEBUG GWT:TPS:Index=0, mqttstr=157
      Aug 15 23:54:42 DEBUG GWT:TPS:Index=1, mqttstr=0
      Aug 15 23:54:42 DEBUG GWT:TPS:Index=2, mqttstr=1
      Aug 15 23:54:42 DEBUG GWT:TPS:Index=3, mqttstr=0
      Aug 15 23:54:42 DEBUG GWT:TPS:Index=4, mqttstr=3
      Aug 15 23:54:42 DEBUG TSF:MSG:SEND,0-0-157-157,s=0,c=1,t=3,pt=0,l=2,sg=0,ft=0,st=OK:35
      Aug 15 23:54:42 DEBUG TSF:MSG:READ,157-157-0,s=0,c=1,t=2,pt=1,l=1,sg=0:1
      Aug 15 23:54:42 DEBUG GWT:TPS:TOPIC=mysensors/all/157/0/1/0/2,MSG SENT
      
      posted in Troubleshooting
      cvdenzen
      cvdenzen
    • RE: Node doesn't receive data from RPI MQTT Gateway

      @evb It took some time (have also another home renovation project), but now I have set up a test gateway.
      The mqtt topic with a slash in its name seems to be the problem. I changed the mqtt topic to mysensorsa and now the sketch receives the message. The mqtt gateway outputs:

      Aug 15 22:50:33 DEBUG GWT:IMQ:TOPIC=mysensorsa/157/0/1/0/3, MSG RECEIVED
      Aug 15 22:50:33 DEBUG TSF:MSG:SEND,0-0-157-157,s=0,c=1,t=3,pt=0,l=2,sg=0,ft=0,st=OK:35
      Aug 15 22:50:34 DEBUG TSF:MSG:READ,157-157-0,s=0,c=1,t=2,pt=1,l=1,sg=0:1
      Aug 15 22:50:34 DEBUG GWT:TPS:TOPIC=mysensors/all/157/0/1/0/2,MSG SENT
      Aug 15 22:50:34 DEBUG TSF:MSG:READ,157-157-0,s=0,c=1,t=3,pt=2,l=2,sg=0:35
      Aug 15 22:50:34 DEBUG GWT:TPS:TOPIC=mysensors/all/157/0/1/0/3,MSG SENT
      

      I will have a look at the MySensors code and if I cannot find the problem, maybe I will change my mqtt subscription topic.

      posted in Troubleshooting
      cvdenzen
      cvdenzen
    • RE: Node doesn't receive data from RPI MQTT Gateway

      Is the mysgw output looking good? The sent message doesn”t include the message type (3). Has anybody tested this with a topic that contains a slash?

      posted in Troubleshooting
      cvdenzen
      cvdenzen