Multi-Choice End Node incl Battery

[camblonie]

Papa,
You clearly have been putting a lot of good work into this, thank you. I downloaded node "2.1g choices battery" which seems to be the latest version. It has a small error on line 646, maybe just make a (3000) delay there. May I suggest you update the first post of the thread with the current version of software to make it easier for folks to know they are using the right version.

I seem to be working backwards now as my system has deteriorated for some reason. I think my gateway computourist v 2.3 is giving me problems. Are you using 2.3 gateway?
Best regards,
Scott

[papa]

Thanks, camblonie / Scott for your response & the encouragement for my efforts on this.

Yes, 2.1g is the latest version. Thanks also for catching the error in it. I have now corrected it:

I added the needed #ifdefPIR before Line 646 & #endif after it. Now when the sketch compiles with the PIR option commented out, it should not throw an error.

The tweaked "g" version is available at the Dec 22, 2015 at 9:04am Post.

Near the "f" sketch's download link, I add a note that a new "g" version is documented, starting with the Dec 14, 2015, 2:59pm Post.

No, I'm not yet using the 2.3 Gateway nor the End Node coding that goes with it. My understanding is that upgrade adds a Device 9 that reports how many re-transmissions are needed. That could be useful for troubleshooting, but my nodes seem to be transmitting just fine so I've not tried it yet.

My Multi-Choice Node sketch (which assumes 2.2 Gateway) may not work with Gateway 2.3 unless Gateway 2.3's Device 9 coding is disabled.

[papa]

Within the Dec 14, 2015 at 2:59pm Post, I document
powering the Multi-Choice Battery Node with a 3.7 volt rechargeable Lithium Ion battery:

        (A battery powered option added on 12/26/2015)
one 3.7 volt rechargeable Lithium Ion Battery charged to about 3.7 volts, a battery box for it, AND one 1N34A Germanium Diode
       Connect battery positive to the diode's UNbanded end. Connect the diode's banded end to the Node's positive rail.
Connect battery negative to the Node's negative/GND rail
        You want a multimeter to register near 3.6 volts across the Node's positive & negative rails.
This voltage should be safe for the RFM69 & power the Node for a good length of time.

[papa]

Update on the Results of Batteries Powering a Multi-Choice End Node:

A few days ago, I removed the Node's DHT11 sensor & uncommented / disabled its sending the DHT11 temperature & humidity data. It now has only a PIR sensor. The node is set to sleep 15 minutes (unless the PIR's detection of motion interrupts it awakes). The node still sends RSSI & voltage & PIR results. For this period, it has been powered by two AA's (alkaline).

For a bit over 4 days, I watched & recorded the voltage changes which were not steady. The voltage seemed to recover somewhat between data sends. It looks like it might have dropped .01 volt or less over the 96+ hours so while the battery pack drops from 3 volts to 2.89 volts, 2 AA batteries might last at least 40 days.  12/28/2015 Update:  So far, the node has dropped .01 volt over about 127 hours.  So 2 AA's might last at least 58 days.

I tried powering the same node with a 3.7 volt Lithium Ion battery plus germanium diode (documented above) & watched its motion-detecting reliability & its voltage changes.

12/27/2015 update:  I'm not thrilled with directly powering a PIR end node with a 3.7v Lithium Ion battery (Lion) plus germanium diode.  The battery voltage was slightly trimmed by the germanium diode & somewhat more by a 1N4148 diode.  This seemed to provide a good, safe voltage for all components, including the RFM69 radio transceiver.  (BIG) however, powered by the Lion battery plus either diode, the PIR sensor permanently stuck in "motion detected" mode & never cleared even when left alone for several sleep / wake periods.  When I reconnected the 2 AA's battery pack (now down to 2.92v), the PIR returned to triggering correctly on motion.

    So far using batteries to directly power a bare bones Arduino PIR (hacked) end node, my best working version uses a two AA battery pack that might last 40 50 days or so.  Gandalph said 3 AA's powered his (3.3v) Arduino Pro Mini with hacked PIR & it had lasted 5 months.  Though voltage regulators (as on the Pro Mini) "waste" some power, they allow one to connect a wider range of source voltages & apparently help smooth power available to the node components.  So far from Gandalph's experience & mine, a hacked PIR works better on a 3.3v Pro Mini powered by 3 or more AA's AND an UNhacked PIR works better on a wall powered (mostly) 3.3v mode Buono Uno where the PIR power source pin connects to the Buono's 5 volt socket.  The 2 better working versions have a voltage regulator on the Arduino device.  The version (the bare bones PIR node) with no voltage regulator works reliably on 2 AA's, but has only fair longevity.

    My recommendation so far for a PIR end node:  If at all possible, use wall power for a (mostly) 3.3v Buono Uno node with an UNhacked PIR.  If you must use battery power, try building a hacked PIR node with a 3.3v Arduino Pro Mini powered by 3 or more AA's.

    From what I saw before, the RFM69 radio transceiver & DHT11 sensor work ok on direct battery power from 2 AA's.  The RFM69 works ok with Lion battery + diode & perhaps the DHT11 sensor would also.

I have resumed using the same 2 AA's to power the bare bones PIR node to see how long the node works with sleeping 15 minutes & awakening to send RSSI, voltage, & PIR status (unless interrupted by the PIR's detecting motion).  Presumably one can increase how long the batteries last if one is willing to make the trade-off of increasing the sleep time.  At some point, I will consider experimenting more with powering bare bones nodes with 3.7v Lion batteries.

    See the 1/1/2016 update below on how the 2 AA batteries are lasting.

[papa]

For my latest recommendation about battery powering a PIR End Node,

see the 12/26/2015 update above

[papa]

12/29/2015 Update: So far, for about 171 hours, the PIR battery node

has still only dropped .01 volt. So 2 AA's might last at least 70-77 days. Not too shabby.

[papa]

1/1/2016 Update: After 218 hours, the PIR battery node documented above

(send data & sleep 15 minutes unless motion interrupts it to report)

had only dropped .01 volt. So 2 alkaline AA's might last at least 90 days, much better results than before.

Data reports every 15 minutes (or immediately when motion detected)
seems a reasonable sweet spot for a battery powered node
especially if one could get 3 months from a couple batteries.

[camblonie]

Papa this is great news. Have you discussed what your sitemap or rules look like for the PIR? I'm thinking a timestamp from the last hit would be nice. Been planning to work on that if I could ever get my issues worked out.

[papa]

You're welcome, camblonie.

For some openhab configs related to the PIR, see the Dec 22, 2015, 9:32am post in this thread.

When motion is detected, the OpenHAB user interface (UI) in a browser should register that fairly quickly.  However, when the PIR returns to the no motion detected state (during the node sleep), it takes a while for that to get sent to the UI.

Yes, especially for the sake of consequent actions, it could be useful to have a time stamp on the last hit (motion detected), also perhaps how long between the last 2 hits.  The latter addition could be easier on a non-battery, non-sleeping node.  But even on the battery node that relies on the watchdog timer (during sleep), one could probably estimate the time between hits close enough.

If you work this PIR time stamp, etc. out, be sure to share. ;-)

[gandalph]

Hi, as the co-tinkerer on the multi-node sketch, Kudo's to you Papa! You have done great work with ironing out some rough patches. I will surely try to get a good grip on your version.

As for the erraticness of the hacked PIR, as you discovered it is quite finnicky indeed. The wait timer combo the version I made of the sketch gave me the best results, but still triggers false positives every now and then (3/wk give or take). I have put some logic in the openhab rules to catch (one off) false triggers, to catch them at the source would be better, but frankly I was sort of fed up with optimizing ;-). I have now in OpenHAB: if PIR triggers, check if it is the first trigger within a 3 second span, if so, do nothing. If its the 2nd trigger then generate an alert).

I have tried to put together some kind of framework with uptime cheking, reporting on nodes being down and voltage reporting as basic telemetry from each node, this can be used for all nodes. For your convenience and entertainment hereby attached the PIR rules and sitemap for you to play with (and improve upon ;-)

cheers!

ps camblonie ; the sitemap line Text item=itm_node2_pir_time shows the last trigger of the PIR in the sitemap (obviously this needs to be accompanied with the corresponding item in the item file) Also the uptime gives me weird (sometimes negative?) values, still need to look into that...)

items

/* NODE 02 PIR Battery Tuinkamer */
DateTime itm_node2_LastUpdate "Last update[%1$ta %1$td %1$tb, %1$tH:%1$tM]" <clock> //PIR tuinkamer
DateTime itm_node2_pir_time "Presence Alarm [%1$ta %1$td %1$tb, %1$tH:%1$tM]" <clock> (PIR_Chart)
Switch itm_node2_pir_alm_enb "Presence Notifier"
Switch itm_node2_pir_alm_sta "PIR Presence Status" <siren>
Switch Night_time "After dark" // for changing alert to alarm
String itm_node2_pir_mqtt "PIR [%s]" (PIR_Chart) {mqtt="<[mymosquitto:home/rfm_gw/nb/node02/dev41:command:on]"}
Number itm_node2_vcc_mqtt "VCC[%.2f V]" <energy> (VCC_Chart) {mqtt="<[mymosquitto:home/rfm_gw/nb/node02/dev04:state:default]"} // node 02, device 4, VCC
Number itm_node2_rssi_mqtt "Signal strength [%.0f RSSI]" <network> {mqtt="<[mymosquitto:home/rfm_gw/nb/node02/dev02:state:default]"} // node 02, device 2, RSSI PIR sensor
Number itm_node2_up_mqtt "Uptime node[%.0f min]" <clock> {mqtt="<[mymosquitto:home/rfm_gw/nb/node02/dev00:state:default]"} // node 02, device 0, upTime mins
Number itm_node2_interval "Interval[%.0f sec]" <clock> {mqtt="<[mymosquitto:home/rfm_gw/nb/node02/dev01:state:default]"} // node 02, device 1, keepalive interval
Number itm_node2_up_mqtt_d "Uptime node [%.1f days]" <clock> // days uptime

rules

var Number PIRTrigger = 0

/* --------- Node2 pir ---------- */


rule "Uber pir threshold - the original" // trigger alert when PIR is ON
       when
               Item itm_node2_pir_mqtt received update
       then
               if(itm_node2_pir_alm_enb.state == ON) // when the alarm is ON then trigger PIR alert
               {
if(PIRTrigger == 1) { // second trigger within 3 seconds is BINGO!
                       sendCommand(itm_node2_pir_alm_sta, ON)
                       // sendCommand(itm_node2_pir_alm_sta, OFF) moved to "Uber PIR Response" to prevent recurring triggers
}
if(PIRTrigger == 0) { // first trigger, might be a glitch/false trigger, reset after 3 seconds
           PIRTrigger = 1
createTimer(now.plusSeconds(3)) [|  PIRTrigger = 0   ]
}
               }
end


rule "Uber PIR alarm is set" // set alarm on between 0.30 and 6.15 each day // obsolete after introduction of the scheduler...
       when
                   Time cron "00 30 00 * * ?"
then
// sendCommand( itm_node2_pir_alm_enb, ON)
Night_time.postUpdate(ON)
end

rule "Uber PIR alarm is turned off" // set alarm on between 0.30 and 6.15 each day // obsolete after introduction of the scheduler...
       when
                   Time cron "00 15 06 * * ?"
       then
// sendCommand( itm_node2_pir_alm_enb, OFF)
Night_time.postUpdate(OFF)
end

rule "Uber pir response" // send an alert after PIR has triggered
       when
               Item itm_node2_pir_alm_sta changed from OFF to ON
       then
               //sendMail("[e-mail]", "pir detected" , "warning!!!")
               //playSound("doorbell.mp3")
               createTimer(now.plusMinutes(2)) [|  sendCommand(itm_node2_pir_alm_sta, OFF)   ] // 2 min Cooldown timer after trigger to prevent multiple alerts
               //postUpdate(itm_node2_pir_time, new DateTimeType())
               itm_node2_pir_time.postUpdate( new DateTimeType() )
               if(Night_time.state == ON){
                Notify_Alert.postUpdate("PIR tuinkamer alarm")
               } else {
Notify_Alert.postUpdate("PIR tuinkamer trigger")
}
end

rule "Uber PIR update time" // last communication received
       when
               Item itm_node2_rssi_mqtt received update
       then
               // postUpdate(itm_node2_LastUpdate, new DateTimeType()) // syntax changed, seems to work better this way...?
               itm_node2_LastUpdate.postUpdate( new DateTimeType() )
end

rule "Node 2 VCC alert" // check for voltage drop, replace batteries
       when
               Item itm_node2_vcc_mqtt received update
       then
if(itm_node2_vcc_mqtt.state < 3.29)
{
Notify_Alert.postUpdate("VCC node 2 at " + itm_node2_vcc_mqtt.state.format("%.2f") + " lower than 3.3V")
}
end


rule "Node 2 out of contact" // no longer receiving communications from a node!
when
Time cron "0 0/5 * * * ?"
then
//   if (!itemXYZ.changedSince(now.minusSeconds(1)) // True if itemXYZ has changes state more than a second ago
   //   if (!itemXYZ.updatedSince(now.minusSeconds(1)) // True if itemXYZ received and update, whether or not the state changed, more than a second ago
     
if(!itm_node2_vcc_mqtt.updatedSince(now.minusMinutes(30))) {
Notify_Alert.postUpdate("PIR Tuinkamer Node last update > 30 min (" + itm_node2_LastUpdate.state + ") (regular update frequency 15 min)")
}
end


  rule "Node 02 mins to days"  // calculate minutes uptime to days for display in sitemap
   when  
     Item itm_node2_up_mqtt changed  
   then  
     var node2_up_days = itm_node2_up_mqtt.state as DecimalType
     postUpdate(itm_node2_up_mqtt_d, node2_up_days/60/24)  
   end
I have MQTTWarn running on my MQTT bus to grab alert triggers, very versatile! required linux though (//notification items for MQTTwarn groups.google.com/forum/#!msg/openhab/HyRhF5xLZXs/diDpFy-lEf8J)

sitemap

    Frame label="Tuinkamer PIR node 2" {
    Text item=itm_node2_LastUpdate
            Text item=itm_node2_up_mqtt_d valuecolor=[itm_node2_LastUpdate=="Uninitialized"="lightgray",itm_node2_LastUpdate>2400="red"]
            Text item=itm_node2_vcc_mqtt valuecolor=[itm_node2_LastUpdate=="Uninitialized"="lightgray",itm_node2_LastUpdate>2400="red",>1500="orange"]
Text item=itm_node2_rssi_mqtt valuecolor=[itm_node2_LastUpdate=="Uninitialized"="lightgray",itm_node2_LastUpdate>2400="red",>1500="orange"]
            Text item=itm_node2_interval valuecolor=[itm_node2_LastUpdate=="Uninitialized"="lightgray",itm_node2_LastUpdate>2400="red",>1500="orange"]
            }

           Switch item=itm_node2_pir_alm_sta mappings=[OFF="Off"]
           Switch item=itm_node2_pir_alm_enb
           Text item=itm_node2_pir_time
// I omitted some lines, as I have also incorporated the "alarm clock II from openhab Wiki to set start and end time for the alarm




[papa]

Thanks, gandalph, for the encouraging co-tinkering. I know what you mean about getting tired of optimizing, esp. when it means redoing the sketch, pulling the chip from the node, reprogramming it on a solderless breadboard, & re-inserting the chip on the node socket.

Some of what you did via OpenHAB configs might address or be parallel to what camblonie & I discussed just above about PIR time stamps, etc.

Thanks for sharing those configs.

I've been hitting this project pretty hard for several months now between my own work & trying to assist others. I'm getting into a period where I need to prepare for some other things. Then I'll have my computer files with me, but I won't be hands on with my OpenHAB network for a few months. So fairly soon there will be limits on what I can contribute with real world testing. Though I likely will check in regularly & offer what help & encouragement I can.

[papa]

Testing Battery Life for a PIR Battery Node ??

        Above on 12/26/2015 at 7:45pm, I wrote,

I have resumed using the same 2 AA's to power the bare bones PIR node to see how long the node works with sleeping 15 minutes & awakening to send RSSI, voltage, & PIR status (unless interrupted by the PIR's detecting motion). Presumably one can increase how long the batteries last if one is willing to make the trade-off of increasing the sleep time. ...

The above were 2 partially used alkaline AA's & I hoped to get some sense of how long batteries would last by watching & recording the progress of voltage drops.  In the updates above, I reported that progress & estimated how long the batteries might last.  I based my estimates on my observation that the node would stop functioning when it reported about 2.89 volts to the user interface.

One tricky aspect is that the node's voltage drops are not steady.  For a while, the node reports a voltage level steadily.  Then it might drop .01 or .02 volts but then "recover" to the former voltage for a long while.

So in this configuration (hacked PIR, sleeping 15 minutes & awakening to send RSSI, voltage, & PIR status (unless interrupted by the PIR's detecting motion), 2 alkaline AA's might last 90 days or it might be more like 55 days.  Hard to be more precise over a voltage drop of .02 volts.

I just installed 2 fresh alkaline AA's from an unopened package.  A multimeter on the power rails reads 3.20 volts & the node reports 3.17 or 3.16 volts.  I plan to let this newly powered node run & watch what happens.  (From what I've seen about batteries, that power above 3 volts goes pretty fast when it's on a load.)

          Above on 12/6/2015, I wrote,

From the data sheets, seems like ATMega328P-PU operates fine 1.8 V to 5.5 V & RFM69 1.8 - 3.6v so 2 AA batteries should work well for them. However, data sheet says DHT11 should operate 3.3 - 6V. One AA in the green on a battery tester reads 1.5 volts on my multimeter & two AA's read 2.99v so I wonder if two AA's would be adequate for the DHT.

Learning along the way:  Pretty well & reliably (if sleep modes are utilized), 2 alkaline AA's will power ATMega328, RFM69, AND a sensor like DHT11 or a hacked PIR (from fresh out of the package down to about 2.89 volts).  Maybe for a couple months, maybe longer.  Perhaps my newest battery test will give a better sense.

I welcome others to use the hardware build & sketch documented above for the battery powered PIR node & to experiment with sleep times.  I'd be glad to hear others' experiences. 

[gandalph]

no worries! with computourists excellent foundation, your work and my contribution this should provide a more than excellent starting point for alot of people. I myself have been out of coding my openhab install for the majority of last year, but am now aiming to add some more sensors to my network (CO2 and Hum to control my mech. ventilation system the coming months.

[papa]

Thanks, gandalph. I look forward to hearing about your next builds & results. I believe it helps to hear what works & also what did not seem to work so well.

[gandalph]

something I forgot to mention... I also destroyed the led on the pro mini to save some more juice. ref: www.mysensors.org/build/battery#measuring-and-reporting-battery-level. Do heed Leif's advice there in the comments: a.disquscdn.com/uploads/mediaembed/images/1903/3183/original.jpg

happy hacking

[gandalph]

Hi, I have made some improvements on your version 2.21f :
- Changed DHT power (VCC) pin to digital pin to lower power consumption by powering down sensor,
- changed interval output to reflect sleep timer when active,
- RSSI value now correcly output in device 2 and
- some minor cosmetic changes
- confirmed to work with DHT alone and on battery with pro mini 3.3v

hereby attached 2.21g

cheers

computourist_node_v2.1g-public.ino (28.9 KB)

ps. still to fix: the uptime counter seems to be broken when in sleep mode. (millis do not work when sleeping)

computourist
papa

[papa]

Thanks, Gandalph. Good to work with you.

That's great that you took care of the digital pin powering the DHT11.  That was on computourist's list for a battery node & I did not get to that.

[papa]

NEW VERSION OF the Multi-Choice End Node with Battery Sipping (version …2.1h)

   computourist_node_v2.1h_choices_battery.ino (35.99 KB)   << Here is the updated sketch.  Documentation follows below.

      << Schematic correction: for the LED use a 1 kilo ohm resistor as safer.
                ^^ Click this Schematic of different possibilities for a Battery-powered node
                  (including using an Arduino digital pin to selectively power a DHT11 sensor on & off)

For a color-coded key showing which connections relate to each component,
look to the left of the ATMega328.

   Computourist Multi-Choice Node-DHT-LED-batt....fzz (46.03 KB)   <<  Fritz showing Battery Node with at least the PIR & digital powered DHT11.

        Updating what I said above in the Dec 8, 2015 at 1:17pm Post …

I reworked the sketches' version numbers so they might indicate their connection to computourist’s work. Gandalph’s & my sketch are based on computourist’s DHT End Node v2.1 which works with Gateway version 2.2. So I renamed Gandalph’s last version as 2.1e. My version here is labeled computourist_node_v2.1g_choices_battery.ino. (I’ll consider updating later to work with a later Gateway version.)

Gandalph & I separately updated my 2.1f version to two different 2.1g versions.  My "g" version increased the choices & customization convenience & tweaked the PIR sensor on battery node.  Gandalph's "g" version:

- Changed DHT power (VCC) pin to a digital pin to lower power consumption by powering down sensor,
- changed interval output to reflect sleep timer when active,   - RSSI value now correctly output in device 2
- some minor cosmetic changes   - confirmed to work with DHT alone and on battery with pro mini 3.3v

This 2.1h version merges the two "g" versions.

The following refers to line numbers in this 2.1h version of the Multi-Choice Node Sketch. In the Arduino IDE, when the cursor is on a line, the IDE tells the line number in the sketch window’s lower left corner. I’ll do my best to give the right location, but editing can change line numbers & is why I say “about line xxx.” In the IDE’s Edit menu is a “go to line” option (or [CTRL] + L) that will let you jump to a given line number.

In many ways, Gandalph’s adaptation was already “multi-choice.” I increased the code lines that those choices included or excluded & tried to clean up some issues.

My intent with most of the below is compactness of code (on the ATMega328 processor), convenience & educational. Compactness: Selecting what code a node only or mostly needs helps to minimize the code in the processor & allow adding more choices. Convenience: I wanted to attempt one sketch that could offer choices to program nodes with different combinations of functions. On the Arduino IDE Serial Monitor, when the node boots up, DEBUG not only shows the sketch version, but also the choices (DHT, SLEEPY, etc). I grouped together as much as possible of what needed customizing.

Educational: I edited & increased comments to help document sketch features & to show where more code sections begin & end. As said below, early #define statements offer choices to tailor a node’s functions. Also later are sections bracketed by #ifdef (or #ifndef) and #endif. Those sections set variables based on whether an earlier #define statement is true or not. By starting with a define statement & then finding later sections testing for that define, I believe a reader could learn much about what is important to that function’s working & how they might adapt or imitate that function. For example, about line 123 says #define HT // for DHT11 temp / humidity sensor. About line 238 says #ifdef HT // DHT11 sensor & then until about line 246 are items set if HT was defined (& the items are not commented (//)) so we see (about line 241), the DHT11 data/out line should connect to Arduino pin 4, etc.

The following customization will tailor things to your components AND to work with openhab-papa++PIR.zip, sample OpenHAB configuration files I supplied earlier & here. I explained how to use the config files in my Success… post Oct 16, 2015 at 4:30pm.  In  this thread, also see the Dec 22, 2015 at 9:32am Post.

Here’s where to edit & customize the Multi-Choice End Node sketch for your setup: About lines 116-142, fairly early in the sketch include a series of #define statements, most commented (start with //). The unedited sketch activates only HT (for DHT11 sensor) & CELS (for Celsius temperature scale.) Uncomment a line to select that option. Leave / make lines commented to negate an option. SLEEPY is the option for a battery-sipping node. (Caution: choosing too many options may cause interference & may tax the node’s available power. Discover by experimenting.)


About lines 149-181 are other items that may need customizing. About line 149, if you already have a node 2, replace NODEID 2 with NODEID xx (xx is new node number). About line 150, replace the “xxxxxxxxxxxxxxxx” with the same 16 character encryption key you created & put into your Gateway Node sketch. About line 151, unless you are programming a battery node, make sure the DEBUG line, is uncommented (NO “//” at the start) at least until you feel confident about your edit of the sketch. To select the frequency of the RFM69 transceivers you have, about lines 153-155, be sure that the same line is uncommented & activated as you did for the Gateway Node & that the other lines are commented.

If & when you build more end nodes, be sure you give each node a unique NODEID about line 149.

If your radio transceiver’s part number include an “H,” UNcomment about line 156. If not, comment it. At line 157 (from here on, line references assume “about”), Txinterval sets how many seconds between the node’s “pushing” or sending data to the gateway (unless in SLEEPY mode). 60 works, but can be changed. At line 158, PIRloops sets how many loops of 8 seconds the node will sleep if battery sipping node has a PIR (now 112 loops = about 15 minutes). At line 159, Loops sets how many 8 second loops the node will sleep between data sends (now 8 loops = 64 seconds) if it’s not a battery-sipping node with a PIR.

When SLEEPY is defined for a battery node, line 174 now sets Arduino digital pin 7 to power the DHT11 sensor on & off to save battery power.  You may change to a different available pin.  See the schematic for how to selectively power the DHT11 sensor using a digital pin.  Caution added 1/8/2016:  Again, to power a node's DHT11 sensor selectively on & off with a digital pin, you must connect the DHT11 as shown in
the above schematic AND you must uncomment line 139 #define SLEEPY.  You may choose SLEEPY for a wall-powered node (& I often test a battery sketch that way), but SLEEPY is particularly intended to help save power on a battery-powered node.

Changes on 1/8/2016:  Line 175 now sets HTdelay to .3 seconds (as gandalph had it) so after pin 7 powers the DHT sensor, the sketch waits before reading temperature & humidity.   Allowing for what data sheets seemed to say, I previously set the delay to 1.1 seconds, but .3 seconds seems to work fine & should be less drain on a battery. You may experiment what delay works best.  Lines 516 (gandalph) & 517 (original computourist) are two approaches to RSSI reporting with somewhat different results.  The sketch downloaded here now uses the original line.  Gandalph's version is there if you want to try it.

Lines 953-956 have other items that may need customizing. Now lines 953 & 954 are commented so the node will NOT send uptime or transmission interval. Now lines 955 & 956 are NOT commented so the node will send signal strength & voltage level. You can change these.

[papa]

    Weather-related items in my openhab-papa.zip & openhab-papa++PIR.zip config packages are not working reliably.

        The following is posted at the OpenHAB wiki related to the weather binding:

"Important changes for Yahoo provider: In January 2016, Yahoo discontinued the service that allows you to use latitude and longitude to locate your weather location. To continue to use the Yahoo weather provider, you must upgrade the weather binding to 1.8.1 or later and supply a woeid (Where On Earth ID) for your location, as shown in the example below. You can find your woeid by copying the numeric digits at the end of the URL for your location at weather.yahoo.com."

However, I see nowhere to download the 1.8.1 version of the weather binding, just 1.8.0.

I installed the 1.8.0 bindings, but that did not help.

For now, I'll wait & see if a 1.8.1 set of bindings appears for download.

[papa]

On my Linux laptop, I received the OpenHAB 1.8.1 updates, but so far I cannot tell if that will cause the weather binding to work.

In the meantime, I'll post the alternative I did get to work via the http binding & Yahoo weather rss:

      ** Go to Yahoo Weather & "Enter city or zip code" in the box provided.
Copy & make note of the several digit number resulting at the end of your browser's address box.

In the My.items config file, find the line that starts "Group Weather_Chart"
      To disable that section for now, change the line to start "/* Group Weather_Chart"
To conclude that disabled section, find the line that starts "DateTime Weather_LastUpdate" & on the following line, type */

      Near the now-disabled section, paste the replacement lines shown below.
After each "w=" replace [Number] with the number you obtained above from Yahoo Weather:
      & If you want Celsius temps, replace each "u=f" with "u=c"

Group Weather_Chart (Weather)
Number Weather_Temperature "Outside Temperature [%.1f °F]" < temperature> (Weather_Chart) { http="<[http://weather.yahooapis.com/forecastrss?w=[Number]&u=f:60000:XSLT(yahoo_weather_temperature.xsl)]" }
Number Weather_Humidity "Outside Humidity [%.1f %%]" <temperature> (Weather) { http="<[http://weather.yahooapis.com/forecastrss?w=2472637&u=f:60000:XSLT(yahoo_weather_humidity.xsl)]" }
Number Weather_Humidex "Humidex [SCALE(humidex.scale):%s]" <comfort_level> (Weather)
Number Weather_Temp_Max "Todays Maximum [%.1f °F]" <temperature> (Weather_Chart) { http="<[http://weather.yahooapis.com/forecastrss?w=[Number]&u=f:60000:XSLT(yahoo_weather_high.xsl)]" }
Number Weather_Temp_Min "Todays Minimum [%.1f °F]" <temperature> (Weather_Chart) { http="<[http://weather.yahooapis.com/forecastrss?w=[Number]&u=f:60000:XSLT(yahoo_weather_low.xsl)]" }
Number Weather_Chart_Period "Chart Period"
DateTime Weather_LastUpdate "Last Update [%1$ta %1$tR]" <clock>

Caution: Sometimes the above works well & resembles what you see on the Yahoo Weather page for your location.
     Sometimes, it gives data that's way off (as for me for one location).
If that happens to you, use the method marked with "**" above to get a number for a nearby location & put that number after each "w=". That worked for me.

[papa]

In a new thread, One Sketch Generates Many Node Functions, I have updated this multi-choice sketch & added new options.

[papa]

I created another new thread, Node Senses Temps in Enclosed or Liquid Areas. It describes a "Freezer" Node that senses temp & humidity outside a freezer (or other enclosure or liquid) AND senses temps inside a freezer (or other enclosure or liquid).

A variation on this node uses TWO waterproof temperature sensors, one of which replaces the DHT11 temp & humidity sensor used in the first variation.

Both can be programmed with a new version of this multi-choice sketch.

[papa]

I created another new thread, Battery-Sipping Node for Mailbox, etc. It gives my take on building & programming a battery-powered (& battery sipping) node that senses & publishes when a mailbox door (or something else) opens & closes. One programs it with a new "Mb" version of my multi-choice sketch.

[papa]

I created a new thread, <success> Wireless Programming>Anarduino Miniwireless</success>. It includes documentation & sketches for accomplishing Wireless Programming with an Anarduino miniwireless (tested & working) & also maybe much of what is needed for a Moteino (untested)

homeautomation.proboards.com/thread/164/success-wireless-programming-anarduino-miniwireless

[papa]

I added a new thread, Multi-choice Node Sketch incl Gateway 2.4 Compatibility.  The new sketch there includes a GW24 option for making a node that takes advantage of the computourist Gateway 2.4 (latest version).