Skip to content
  • MySensors
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. OpenHardware.io
  3. 💬 MyMultisensors

💬 MyMultisensors

Scheduled Pinned Locked Moved OpenHardware.io
328pmotionatsha204amulti sensorhumiditytemperaturepirambiant lightlow powercoincell
176 Posts 33 Posters 61.2k Views 35 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • scalzS Offline
    scalzS Offline
    scalz
    Hardware Contributor
    wrote on last edited by
    #121

    @alexsh1
    sure PIR state is 0 or 1. I'm not changing anything to this. But you can fine tune this.

    Do you mean you'll update each time there is a CHANGE ?? No intermediate state ??
    If so, you'll waste a lot of power in useless radio TX, mcu processing, depending on days and traffic. and your batteries won't last for long!

    When there are people for an hour in same room, do you update each time it triggers? That can be a lot of waste!
    Also why not allowing a blindtime before redecting?
    In days with lot of traffic at home for example. If you already know (or the controllers could adjust this dynamically too by custom commands) that a room will be busy. It's useless and will consumes power again, to send 0 if it will retrigger in just a few seconds.

    So i've done sort of helper for creating intermediate states with timeouts and counters, with user defines etc.

    alexsh1A 1 Reply Last reply
    0
    • scalzS scalz

      @alexsh1
      sure PIR state is 0 or 1. I'm not changing anything to this. But you can fine tune this.

      Do you mean you'll update each time there is a CHANGE ?? No intermediate state ??
      If so, you'll waste a lot of power in useless radio TX, mcu processing, depending on days and traffic. and your batteries won't last for long!

      When there are people for an hour in same room, do you update each time it triggers? That can be a lot of waste!
      Also why not allowing a blindtime before redecting?
      In days with lot of traffic at home for example. If you already know (or the controllers could adjust this dynamically too by custom commands) that a room will be busy. It's useless and will consumes power again, to send 0 if it will retrigger in just a few seconds.

      So i've done sort of helper for creating intermediate states with timeouts and counters, with user defines etc.

      alexsh1A Offline
      alexsh1A Offline
      alexsh1
      wrote on last edited by
      #122

      I would only update each time there is a first HIGH. Then the node goes to unconditional sleep for 30-60 sec - there is no need to send HIGH again or LOW. After 1 min the status in Domoticz for the PIR is cleared (LOW) and the PIR is ready to send another "HIGH" if triggered.

      Can Domoticz really adjust PIRs dynamically?
      There is blockly stript, which helps to process "HIGH" from a PIR, but I'm not aware how this can done dynamically.

      Clearly, you approached this as a programmer. I have a much more simplified approach. Maybe because I'm noobs when it comes to PIRs

      @scalz said in 💬 MyMultisensors:

      @alexsh1
      sure PIR state is 0 or 1. I'm not changing anything to this. But you can fine tune this.

      Do you mean you'll update each time there is a CHANGE ?? No intermediate state ??
      If so, you'll waste a lot of power in useless radio TX, mcu processing, depending on days and traffic. and your batteries won't last for long!

      When there are people for an hour in same room, do you update each time it triggers? That can be a lot of waste!
      Also why not allowing a blindtime before redecting?
      In days with lot of traffic at home for example. If you already know (or the controllers could adjust this dynamically too by custom commands) that a room will be busy. It's useless and will consumes power again, to send 0 if it will retrigger in just a few seconds.

      So i've done sort of helper for creating intermediate states with timeouts and counters, with user defines etc.

      Sergio RiusS 1 Reply Last reply
      0
      • alexsh1A alexsh1

        I would only update each time there is a first HIGH. Then the node goes to unconditional sleep for 30-60 sec - there is no need to send HIGH again or LOW. After 1 min the status in Domoticz for the PIR is cleared (LOW) and the PIR is ready to send another "HIGH" if triggered.

        Can Domoticz really adjust PIRs dynamically?
        There is blockly stript, which helps to process "HIGH" from a PIR, but I'm not aware how this can done dynamically.

        Clearly, you approached this as a programmer. I have a much more simplified approach. Maybe because I'm noobs when it comes to PIRs

        @scalz said in 💬 MyMultisensors:

        @alexsh1
        sure PIR state is 0 or 1. I'm not changing anything to this. But you can fine tune this.

        Do you mean you'll update each time there is a CHANGE ?? No intermediate state ??
        If so, you'll waste a lot of power in useless radio TX, mcu processing, depending on days and traffic. and your batteries won't last for long!

        When there are people for an hour in same room, do you update each time it triggers? That can be a lot of waste!
        Also why not allowing a blindtime before redecting?
        In days with lot of traffic at home for example. If you already know (or the controllers could adjust this dynamically too by custom commands) that a room will be busy. It's useless and will consumes power again, to send 0 if it will retrigger in just a few seconds.

        So i've done sort of helper for creating intermediate states with timeouts and counters, with user defines etc.

        Sergio RiusS Offline
        Sergio RiusS Offline
        Sergio Rius
        wrote on last edited by
        #123

        @alexsh1
        My domoticz installation does not resets Pirs after a minute or whenever. Are you using the PIR lua scripts or any other?
        By default it doesn't do such thing.

        alexsh1A 1 Reply Last reply
        0
        • scalzS Offline
          scalzS Offline
          scalz
          Hardware Contributor
          wrote on last edited by scalz
          #124

          @alexsh1 i have this option too (ctrl clearing pir state) i thought it could depend on the controller used, so i've tried to make something independant. And i like adding features like setting triggers max for a motion etc. But i agree, your way works too ;)

          alexsh1A 1 Reply Last reply
          0
          • Sergio RiusS Sergio Rius

            @alexsh1
            My domoticz installation does not resets Pirs after a minute or whenever. Are you using the PIR lua scripts or any other?
            By default it doesn't do such thing.

            alexsh1A Offline
            alexsh1A Offline
            alexsh1
            wrote on last edited by alexsh1
            #125

            @Sergio-Rius either you have to use lua or there is a much simpler way to do it in Domoticz. Change type to "motion sensor" and then you have an option "off delay". Setup it to 60 seconds and PIR sensor will be off in 60 seconds. Very useful option and yes it is not enabled by default.0_1497139322273_IMG_5170.PNG

            1 Reply Last reply
            1
            • scalzS scalz

              @alexsh1 i have this option too (ctrl clearing pir state) i thought it could depend on the controller used, so i've tried to make something independant. And i like adding features like setting triggers max for a motion etc. But i agree, your way works too ;)

              alexsh1A Offline
              alexsh1A Offline
              alexsh1
              wrote on last edited by
              #126

              @scalz can your controller adjust PIRs dynamically?
              What controller are you using please?

              1 Reply Last reply
              0
              • scalzS Offline
                scalzS Offline
                scalz
                Hardware Contributor
                wrote on last edited by
                #127

                @alexsh1 i just said i have same option as you in my controller :) My controller is jeedom (french ctrlr)
                I've not done it yet (missing time), but i would use some script and scenario if i would like to dynamically adjust this vs some parameters.

                1 Reply Last reply
                0
                • alexsh1A Offline
                  alexsh1A Offline
                  alexsh1
                  wrote on last edited by
                  #128

                  @scalz How are you dealing with PIR? It is connected to D6 and D7, but sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, SLEEP_TIME); can only be used with D2 and D3 or I am mistaken? Maybe you can share your motion sketch please?

                  1 Reply Last reply
                  0
                  • scalzS Offline
                    scalzS Offline
                    scalz
                    Hardware Contributor
                    wrote on last edited by scalz
                    #129

                    @alexsh1 I'm using pinchange interrupts. It is not supported in Mysensors out of box regarding sleep, if i remember, i made some change to my functions, but the lib has changed a bit. that would need i check the code and i have no time for the moment, and don't want to release something not up to date. will take a look later, don't know when yet.

                    But if that can help, below is some parts of code, for enabling your irqs, and the interrupts routine. I think if you're using sleep from MySensors, it will return -1 if triggered by the pinchange, that's all. you'll just need to handle that in your sketch.

                    ISR (PCINT1_vect) 
                    {
                      if (digitalRead(AMBIANT_LIGHT_PIN)) 
                        irqLight = false;  
                      else 
                        irqLight = true; 
                    }  
                    
                    ISR (PCINT2_vect) 
                    {
                      if((PIND & (1 << PIND6)) == 0x40 ) {  
                    	  myPirSensor.pirhCount++;  
                    		myPirSensor.irqPir = true;  
                    	}
                      if((PIND & (1 << PIND7)) == 0x80 ) {  
                    	  myPirSensor.pirlCount++;  
                    		myPirSensor.irqPir = true;  
                    	}        
                    } 
                    
                    /* ======================================================================
                    Function: pirIntEnable
                    Purpose : Enable pin change for PIR interrupt
                    Input   : -
                    Output  : -
                    Comments:  
                    ====================================================================== */ 
                    void pirIntEnable() 
                    {
                      // Enable pin change for D6, D7
                      PCMSK2 |= bit (PCINT22);  
                      PCMSK2 |= bit (PCINT23);  
                      PCIFR  |= bit (PCIF2);   // clear any outstanding interrupts
                      PCICR  |= bit (PCIE2);   // enable pin change interrupts for D0 to D7 
                    }
                    /* ======================================================================
                    Function: pirIntDisable
                    Purpose : Disable pin change for PIR interrupt
                    Input   : -
                    Output  : -
                    Comments:  
                    ====================================================================== */ 
                    void pirIntDisable() 
                    {
                      // Disable pin change for D6, D7
                      PCICR  ^= bit (PCIE2);   // disable pin change interrupts for D0 to D7 
                    }
                    /* ======================================================================
                    Function: lightIntEnable
                    Purpose : Enable pin change for OPT3001 interrupt
                    Input   : -
                    Output  : -
                    Comments:  
                    ====================================================================== */ 
                    void lightIntDisable() 
                    {
                      PCMSK1 |= bit (PCINT9);  
                      PCIFR  |= bit (PCIF1);   // clear any outstanding interrupts
                      PCICR  |= bit (PCIE1);   // enable pin change interrupts for A0 to A5   
                    }
                    /* ======================================================================
                    Function: Light_IntDisable
                    Purpose : Disable pin change for OPT3001 interrupt
                    Input   : -
                    Output  : -
                    Comments:  
                    ====================================================================== */ 
                    void lightIntDisable() 
                    {
                      PCICR  ^= bit (PCIE1);   // disable pin change interrupts 
                    }
                    
                    alexsh1A 1 Reply Last reply
                    1
                    • scalzS scalz

                      @alexsh1 I'm using pinchange interrupts. It is not supported in Mysensors out of box regarding sleep, if i remember, i made some change to my functions, but the lib has changed a bit. that would need i check the code and i have no time for the moment, and don't want to release something not up to date. will take a look later, don't know when yet.

                      But if that can help, below is some parts of code, for enabling your irqs, and the interrupts routine. I think if you're using sleep from MySensors, it will return -1 if triggered by the pinchange, that's all. you'll just need to handle that in your sketch.

                      ISR (PCINT1_vect) 
                      {
                        if (digitalRead(AMBIANT_LIGHT_PIN)) 
                          irqLight = false;  
                        else 
                          irqLight = true; 
                      }  
                      
                      ISR (PCINT2_vect) 
                      {
                        if((PIND & (1 << PIND6)) == 0x40 ) {  
                      	  myPirSensor.pirhCount++;  
                      		myPirSensor.irqPir = true;  
                      	}
                        if((PIND & (1 << PIND7)) == 0x80 ) {  
                      	  myPirSensor.pirlCount++;  
                      		myPirSensor.irqPir = true;  
                      	}        
                      } 
                      
                      /* ======================================================================
                      Function: pirIntEnable
                      Purpose : Enable pin change for PIR interrupt
                      Input   : -
                      Output  : -
                      Comments:  
                      ====================================================================== */ 
                      void pirIntEnable() 
                      {
                        // Enable pin change for D6, D7
                        PCMSK2 |= bit (PCINT22);  
                        PCMSK2 |= bit (PCINT23);  
                        PCIFR  |= bit (PCIF2);   // clear any outstanding interrupts
                        PCICR  |= bit (PCIE2);   // enable pin change interrupts for D0 to D7 
                      }
                      /* ======================================================================
                      Function: pirIntDisable
                      Purpose : Disable pin change for PIR interrupt
                      Input   : -
                      Output  : -
                      Comments:  
                      ====================================================================== */ 
                      void pirIntDisable() 
                      {
                        // Disable pin change for D6, D7
                        PCICR  ^= bit (PCIE2);   // disable pin change interrupts for D0 to D7 
                      }
                      /* ======================================================================
                      Function: lightIntEnable
                      Purpose : Enable pin change for OPT3001 interrupt
                      Input   : -
                      Output  : -
                      Comments:  
                      ====================================================================== */ 
                      void lightIntDisable() 
                      {
                        PCMSK1 |= bit (PCINT9);  
                        PCIFR  |= bit (PCIF1);   // clear any outstanding interrupts
                        PCICR  |= bit (PCIE1);   // enable pin change interrupts for A0 to A5   
                      }
                      /* ======================================================================
                      Function: Light_IntDisable
                      Purpose : Disable pin change for OPT3001 interrupt
                      Input   : -
                      Output  : -
                      Comments:  
                      ====================================================================== */ 
                      void lightIntDisable() 
                      {
                        PCICR  ^= bit (PCIE1);   // disable pin change interrupts 
                      }
                      
                      alexsh1A Offline
                      alexsh1A Offline
                      alexsh1
                      wrote on last edited by
                      #130

                      @scalz said in 💬 MyMultisensors:

                      Thank you for sharing it.
                      I must admit, it does look Chinese to me. I have never come across pinchange interrupts so have to dive in to understand it.

                      1 Reply Last reply
                      0
                      • alexsh1A Offline
                        alexsh1A Offline
                        alexsh1
                        wrote on last edited by
                        #131

                        My sensor is now fully completed with all sensors and flash. I decided to go for 2450 battery

                        0_1498299022820_IMG_5438.JPG

                        0_1498299079412_IMG_5440.JPG

                        1 Reply Last reply
                        2
                        • scalzS Offline
                          scalzS Offline
                          scalz
                          Hardware Contributor
                          wrote on last edited by scalz
                          #132

                          @alexsh1
                          beautiful !
                          about pin change interrupt, that would be too bad, to be restricted to D2, D3 only :)
                          there are multiple howtos which show how to use them. mcu datasheet section is also interesting. not that hard, don't worry.
                          you'll need to clean the code above a bit to fit your sketch (variables etc). the counters on pinh and pinl were for tests, you can factorize a bit pir isr and use only one volatile variable for your trigger etc.

                          Have fun

                          1 Reply Last reply
                          0
                          • CarywinC Offline
                            CarywinC Offline
                            Carywin
                            wrote on last edited by
                            #133

                            Here's my first 5 multi-sensors assembled and they've passed simple hardware tests. Although I think I have 2 that have PIRs that won't settle down. Thanks for the design scalz!
                            0_1500541753297_Photo 20-7-17, 16 56 10.jpg
                            Now to write some firmware for them... Any hints?

                            TerrenceT 1 Reply Last reply
                            1
                            • CarywinC Carywin

                              Here's my first 5 multi-sensors assembled and they've passed simple hardware tests. Although I think I have 2 that have PIRs that won't settle down. Thanks for the design scalz!
                              0_1500541753297_Photo 20-7-17, 16 56 10.jpg
                              Now to write some firmware for them... Any hints?

                              TerrenceT Offline
                              TerrenceT Offline
                              Terrence
                              wrote on last edited by
                              #134

                              @Carywin Wow, those look really great, please keep us posted on your progress.

                              1 Reply Last reply
                              0
                              • CarywinC Offline
                                CarywinC Offline
                                Carywin
                                wrote on last edited by
                                #135

                                I've been slowly poking at these boards and I'm getting somewhere with the firmware, I should have something ready to put out there soon.

                                In the meantime though I designed a quick snap-together enclosure that I'm sending off for "Dirty" 3D printing:
                                0_1501094332438_render.png

                                This is my first time using Fusion 360 and designing something for 3D printing, hopefully it goes okay.

                                I wanted it to snap together in two halves around the board and be as low-profile as possible, hence why the base plate only covers half of the PCB and is mounted by one screw only. I designed it around using a CR2450 battery. I might also see if I can find a small lens or light pipe to put over the lux sensor so it gets a better read on the light level in the room.

                                1 Reply Last reply
                                2
                                • CarywinC Offline
                                  CarywinC Offline
                                  Carywin
                                  wrote on last edited by Carywin
                                  #136

                                  Okay, so here's some firmware I wrote for these multi-sensors: https://github.com/carywin/MySensors/tree/master/MyS_MultiSensor_revB

                                  Note that I'm currently using MySensors 2.2-beta from the development branch, to solve the some other problems I was having in my RFM69-based gateway. This sketch should still work fine with the released version of MySensors but I haven't tested it.I'm still testing and refining things here and there, but it should be a working base for people to build from. Of course you will need to change the MySensors #defines to match your network and radio settings.

                                  You'll probably notice that all of the sensors report under the same Child ID as a "Custom Sensor". This is because I'm using OpenHAB via an MQTT broker, so I don't really care if a certain sensor type matches with its provided variable types. If you're using a different controller, you may have to re-jig the Child ID/Variable types to match the known-working sensors on your controller.

                                  PIR Sensor:
                                  The PIR sensor is interrupt driven and will send a message when it receives more than 5 pulses in less than 5 seconds. After triggering, the interrupt is disabled for 60 seconds. If it receives fewer than 5 pulses then approx. 5 seconds after the last pulse it will reset the pulse counter. For the first 30 seconds after power-on, the PIR interrupts are disabled to allow the signal conditioning circuit time to settle. All of these values are configurable in the sketch. Note that I'm using GreyGnome's EnableInterrupt library, which you'll need to get from their Github.

                                  Lux Sensor:
                                  The lux level sensor will send a new reading to the controller when the lux reading moves outside a window threshold from the current reading, which is configurable in the sketch. It also takes a new reading after a certain period with no changes in lux, which is also configurable in the sketch.
                                  Note that you'll need the specific version of the OPT3001 library from the above link copied into your libraries folder. I modified the library to spit out raw values and allow the setting of thresholds, so the lux sensor can do most of the heavy lifting with regards to monitoring light levels and flagging an interrupt when it changes. Note that when the lux readings are very low, such as around sunrise and sunset, the threshold values are fixed to prevent excessive lux sensor messages.

                                  Door Sensor:
                                  The D3 pin input is set to trigger an interrupt on state change, which will send its new state to the controller on each change. It's pulled high by an on-board resistor so the input pullup is disabled to save energy.

                                  Temp & Humidity Sensor:
                                  Temperature and humidity are read at regular intervals (default 10 min), and new values only sent if the they have changed by 0.1 degC or 1% RH. If a certain number of intervals pass with no change (default 3 hours) they will send new values anyway. This way the controller can expire their readings after 3 hours and ignore stale values, and you can get an indication that maybe your sensor has failed. The interval times are configurable in the sketch. I'm using the Adafruit SI7021 library which you can get from their Github.

                                  Battery:
                                  Once a day by default the sensor will report battery voltage as a sensor, and remaining capacity as a percentage using the in-built reporting function. The full and empty thresholds as well as reporting interval are configurable in the sketch. Note that the method used to measure battery voltage has a large margin for error, but that this can mostly be calibrated out. For this reason you'll see a VCC calibration value that you should set by measuring each sensor's battery voltage with a multimeter, and comparing with its reported battery volts.

                                  WDT:
                                  I'm using the WDT during the time when the code isn't asleep, with a timeout of 2 seconds. This should be more than enough to send all of the sensor messages needed each cycle, but I haven't extensively tested that. I included it because in revision A I was suffering some kind of unknown lock up that would keep the MC awake and drain the coin cell battery in just a few hours. Of course the WDT is used by the library for timing the sleep intervals, so it gets re-enabled each wake up.

                                  Because timing how long an Arduino has been asleep is difficult without a RTC, the sleep time may vary somewhat depending on how many interrupts the sensor receives. Each time the MC is woken from sleep by an interrupt, it reduces the amount of time it will sleep next time by 25%. In addition to this, if more than 25 interrupts occur before a new round of sensor readings are taken, then the interval will be declared over and the sensors read again. These are crude methods for timing but so far it seem to be reliable in that the sensor neither sleeps forever nor spams excessively when receiving realistic rates of interrupt.

                                  I welcome any input people have on this project and ways that this might be improved.

                                  1 Reply Last reply
                                  2
                                  • scalzS Offline
                                    scalzS Offline
                                    scalz
                                    Hardware Contributor
                                    wrote on last edited by
                                    #137

                                    @Carywin
                                    Good work :+1:
                                    I will take a look when i'll have more time.

                                    1 Reply Last reply
                                    0
                                    • Adi VacaruA Offline
                                      Adi VacaruA Offline
                                      Adi Vacaru
                                      wrote on last edited by
                                      #138

                                      I was wondering why didn't you use a open drain comparator and you could have or-ed your outputs using only one MCU pin ?

                                      1 Reply Last reply
                                      0
                                      • scalzS Offline
                                        scalzS Offline
                                        scalz
                                        Hardware Contributor
                                        wrote on last edited by
                                        #139

                                        because there was already enough parts on board, for power consumption and wanted to save as much as i could with this design.
                                        The prototype had it though, but i removed it because that was useless as there are more than enough pins for this on mcu.

                                        1 Reply Last reply
                                        1
                                        • Adi VacaruA Offline
                                          Adi VacaruA Offline
                                          Adi Vacaru
                                          wrote on last edited by
                                          #140

                                          good answer ! it's not a good one for those of us that are less 'code gifted'. but anyway good work for the design.i would have to study how i can get it to work in code.

                                          1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          11

                                          Online

                                          11.7k

                                          Users

                                          11.2k

                                          Topics

                                          113.0k

                                          Posts


                                          Copyright 2019 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
                                          • Login

                                          • Don't have an account? Register

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • MySensors
                                          • OpenHardware.io
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular