Posts made by GertSanders

@Raj-Kiran you can use any 3mm LED. So the best is to choose the cheapest 3mm you can find on ALIEXPRESS.

@mfalkvidd It's been a while since I checked the forums and site, and I'm happy to see the changes, great job ! Work took over for some time, but the Corona period has given some free time, so I was able to finish my clock.

@mfalkvidd It would be good if DXF files are supported, because box outlines made in autocad or (as in my case in Eagle and exported to DXF) other programs can be used as input on lasercutter software. Most lasercutter sites accept DXF directly.

@mfalkvidd indeed, and yes I did, but dropping a DXF file gave an error saying it was a wrong file format. Did I miss something ?

I was wondering how I should load a DXF file, so that I can provide the basis of a lasercutter file.
Any tips ?

@vladimir

you could use this under the bed:

https://www.aliexpress.com/item/Free-Shipping-5-Pieces-RCWL-0516-Microwave-Radar-Sensor-Module-Human-Body-Induction-Switch-Module/32773310756.html?spm=a2g0s.9042311.0.0.27424c4dQaNm0K

It works like an infrared sensor (same three pins), but it does not need a line of sight. It just reacts to movement as this results in a disturbance in the emitted radio signal. Works very well on my clock

The "high" value when movement is detected is not a full 5V, so I test the Out pin as an analog pin. Anything above 2.5V is an activation due to movement.

@mfalkvidd I set it to 1000ms, but the jumps are sometimes 3 - 4 seconds. I was hoping that shutdownTransport() would do the trick. But that does not seem to help. It looks like I need to define a hardware_shutdown button or something.

I'm building a MySensors aware clock. However, I need to provide for the situation that the netwerk is down (gateway without power, or not installed). Or there could be a problem with the radio. In all cases I want the clock to still start up and run without apparent slowdown.
What I found was, that when I do not install a radio, the MySensors library is aware of this (a FALSE result from isTransportReady() ), but the MySensors code seems to take it's time and hog the processor by trying to reconnect.
This is visible on my clock, because the time on the display seems to "freeze" for some seconds. As I use a real RTC, this not really a big problem, but it is visible none the less. And being a perfectionist, I do not want a clock which seems to jump a few seconds now and then.
So the question is how to skip these processor intensive parts if the user accepts that the clock should work without MySensors integration.
Any suggestion is fine

Is there a way to completely shutdown all MySensors code via code (not via compile defines, but a decision made in code) ?

@neverdie that is a nice pattern. I found that these things need time to draw. If anyone has a DXF file, I would love to try it.

is there a #define symbol for the first really free EEPROM address ?

From the .h file I gather that EEPROM_LOCAL_CONFIG_ADDRESS and higher are free of my own use ???

@neverdie I will publish the project once it has advanced a bit more (still need to design the PCB for this box).

@neverdie nope, but it is inspired by oriental frames, I just made that based on what I saw on one of my cabinets (which I bought while living in Singapore).

One of three ongoing projects:

lasercut box
atmega1284p based
DS3231 rtc (very accurate and 2 alarms!)
LDR
20 by 4 LCD, two sizes of numbers, menu driven setup
buzzer
leds for moodlighting
doppler for proximity detection
encoder for scrolling through values (for setting time)
buttons with LED feedback for interactivity
mp3 player
most interface objects MySensorised

This entry is to boost my energy, because we are still a long way from home (pcb is still not made, focus is now on prototype and software).

@mfalkvidd
Nope, I probably got this from a forum message somewhere. I’m not sure where I got the suggestion to use the define.
The thing is, it is very nice to have this #define, but as @Neverdie said, it would be nice to avoid that a node “hangs” if the gateway is unavailable. As far as I can see, there is no DEBUG message if the network is not reachable. And for a new MySensors user a hanging node is really confusing (it is sometimes for me as well). So this #define will now be part of me ‘default’ template until the standard behaviour is adapted.

@mfalkvidd from an example where it mentioned

#define MY_TRANSPORT_WAIT_READY_MS 5000

I would expect this to be the default, and not '0'

@mfalkvidd

I'm not sure if the current default behaviour of MySensors is to wait for 5 seconds before giving up and moving on. I was under the impression that a node would try to find a network until my hair grows back.

When the define is included in the sketch, it clearly does it's job.

@NeverDie probably meant that we should not need to set the define, unless we want to change the default 5sec wait time, or if we explicitly want to have the node hang until a network is found.

So the question is, is the default behaviour to keep looking for a network, or does the library stop after 5sec and move on with the setup() ?

@pihome I have now used it first as a serial gateway. Now I'm using it as a ethernet gateway (since Raspberry gateway code is now included in MySensors build).

@gertsanders [SOLVED]: a wrong type in a declaration gave constant '0' values. Now corrected and distances is now measured correctly.

Does anyone have a working example of the combination NewPing 1.9 and MySensors 2.2.0 ?

I keep getting distance = 0, while the basic distance sensor sketch works perfectly (on the same setup), so the hardware side is OK.

@alexsh1
I have a DIL connector on my PCB, and the nrf24l01+ plugs into it. On my testboard I'm still using the non-smd version.

@alexsh1 hi Alex, it is how I routed my PCB.

@gohan I would love to have that feature so I can send updates to a LCD equipped sensor, without the "switch" hack.
Polling is really inefficient, one should be able to send V_TEXT just like V_STATUS.

@petjepet

As @gohan mentioned, you need to add the test in the loop. But you can also add it to the setup() function. I did find that sometimes the link with the network is not yet active at the start of setup(). But by the end of the setup() (in my case I need to start several objects), it is usually OK.

The define is just so that a timout is limited. I found 5 seconds a bit long, so I set it to 2 seconds

#define MY_TRANSPORT_WAIT_READY_MS 2000

and then in code I test:

void loop() {
if (isTransportReady())
{
// do stuff with network in place
}
else
{
// do stuff without network in place
}

} // end of loop()

@alexsh1

MISO, MOSI and SCK are connected to the pins that carry this function
CE -> PB1
CSN -> PB4

I use PB0 to show a flashing in the bootloader.

I'm now using this define MY_TRANSPORT_WAIT_READY_MS to get a "timeout" and I also use isTransportReady() to check if my device needs to work in stand-alone mode or if it is connected to the MySensors network once I exit the setup() fase.

I do not need to do node to node signalling without GW, but the info provided is nice to know

@รอเร-อ

We found that in the following directory you can remove the platform.txt file:

/hardware/atmega328p/avr/platform.txt

The directory should only contain boards.txt and the subdirectories for boot loaders and variants

I have a question I could not answer based on the documentation:

Is there a way to check presence of a MySensors network, and proceed without if not found ?

I would like to make a device that connects to a MySensors network if there is one, but can go into "standalone" mode if no network is present.

Right now it seems the node keeps trying to connect and never reaches the setup() function. It does pass the before() function.

@alexsh1
SOLVED: the problem with my atmega1284p was the mapping of the CE pin.
I needed to add the following to my sketch:
#define MY_RF24_CE_PIN 1
The reason is that I used a "standard" pinout, so CE is not on Arduino pin 9.
In my pin-definition "CE" is Arduino pin 1 or chip pin PB1.
There are several mappings possible for this chip:
https://github.com/MCUdude/MightyCore
So I need to look at the pin mapping again, and may refresh the boot loader with one of the MightyCore boot loaders ( I flashed this chip back in early 2015).

I use the following mapping:

// ATMEL ATMEGA1284P
//
//                   +---\/---+
//           (D 0) PB0  1|        |40  PA0 (AI 0 / D24)
//           (D 1) PB1  2|        |39  PA1 (AI 1 / D25)
//      INT2 (D 2) PB2  3|        |38  PA2 (AI 2 / D26)
//       PWM (D 3) PB3  4|        |37  PA3 (AI 3 / D27)
//    PWM/SS (D 4) PB4  5|        |36  PA4 (AI 4 / D28)
//      MOSI (D 5) PB5  6|        |35  PA5 (AI 5 / D29)
//  PWM/MISO (D 6) PB6  7|        |34  PA6 (AI 6 / D30)
//   PWM/SCK (D 7) PB7  8|        |33  PA7 (AI 7 / D31)
//                 RST  9|        |32  AREF
//                 VCC 10|        |31  GND 
//                 GND 11|        |30  AVCC
//               XTAL2 12|        |29  PC7 (D 23)
//               XTAL1 13|        |28  PC6 (D 22)
//      RX0 (D 8)  PD0 14|        |27  PC5 (D 21) TDI
//      TX0 (D 9)  PD1 15|        |26  PC4 (D 20) TDO
// RX1/INT0 (D 10) PD2 16|        |25  PC3 (D 19) TMS
// TX1/INT1 (D 11) PD3 17|        |24  PC2 (D 18) TCK
//      PWM (D 12) PD4 18|        |23  PC1 (D 17) SDA
//      PWM (D 13) PD5 19|        |22  PC0 (D 16) SCL
//      PWM (D 14) PD6 20|        |21  PD7 (D 15) PWM
//                   +--------+
//

And there is some renaming here:

static const uint8_t SS   = 4;
static const uint8_t MOSI = 5;
static const uint8_t MISO = 6;
static const uint8_t SCK  = 7;

static const uint8_t SDA = 17;
static const uint8_t SCL = 16;
static const uint8_t LED = 7;

static const uint8_t A0 = 24;
static const uint8_t A1 = 25;
static const uint8_t A2 = 26;
static const uint8_t A3 = 27;
static const uint8_t A4 = 28;
static const uint8_t A5 = 29;
static const uint8_t A6 = 30;
static const uint8_t A7 = 31;

So most pins mapped correctly, except for CE ...

fixed now with the #define

@alexsh1 nope. The atmega328p's all work properly and get recognised. The atmega1284p never gets a reply.
I'm wondering if it has to do with the selection of pinout. I selected "Standard" pinout, which is a pin definition used in AVR Freaks site. There is also Bobuino and Sanguino. Still need to test those.

@alexsh1 hi Alex, yes.I was testing stuff with my first atmega1284p arduino clone (made back in 2015). The plan is now to make a smart clock with the mighty beast (lots of program memory, especially nice for extensive menu's).
But I'm a bit stuck on the fact that I can not get my node recognised on the Domoticz/gateway combo (on a raspi 2).
At least the compile error is now gone. Onto the next problem: no reply from parent ...

So here is my contribution to this tread: a differential drive "brain". A work in progress:

I'm seeing exactly the same with my atmega1284p based sensor, the atmega328p based sensors do get replies from the gateway, FPAR does get a response on my atmega328p sensors.
Maybe this is a timing issue ?

@DavidZH @alexsh1
The solution to removing the error was indeed to update the platform.txt file.
I copied the official platform.txt file from the Arduino application to the hardware folder in where my definitions and boot loader sit. The old platform.txt was renamed, and I added the official platform.txt instead.
That worked.
I'm assuming that by removing the platform.txt file, the Arduino IDE reverts to it's own platform.txt file, and as I can not see any parameters specific to the atmega328p or other processors, it was probably safe to remove this file.
I also tested this, and that also solved the error message problem.

@gohan
Indeed, it is a Domoticz beta issue

@davidzh

I can add to this: also the other bootloaders I use have a problem at the same point. The PSTR() expansion seems to fail. I have this same issue with the MightyCore bootloader and with Optiboot 6.x

The thing is, my atmega328p based nodes work fine without the MY_DEBUG flag.

So could this be related to the hardware definition ? Looks like it. I will test this further with the suggestion by Alex.

I went back to the stable release of Domoticz, still use the beta ethernet gateway and now presentation of sensors is back to normal.
But it all started with the fact that I wanted to include a sensor based on the atmega1284p. That still seems to be a probem. The code on the sensor side is the Arduino MySensors library (2.2.0).
So as an update: presentation of sensors does crash on 9379, still waiting for a newer version of Domoticz before I move to the beta again.

Just to let people know: the latest beta build of Domoticz (9379) crashes when you add a new sensor. Sometimes it doen register a sensor, but this becomes evident only after restarting the Raspberry completely.
My setup:
Raspberry Pi 2
Radio NRF24L01+ (large SMD model with amplifiers) connected to GPIO pins
Gateway is built based on the BETA (git clone of development branch) (2.3.0-alpha)
Sensors are recompiled in Arduino with the stable 2.2.0 version. The sensors that seems to work (after crashing and restarting the RPi) are based on atmega328p.
I have a "test" sensor based on atmega1284p which does not get an ID from the controller. Does not even find the parent to start with.

@dbemowsk like to push my luck I guess
It seems the latest Domoticz beta (9379 build date 28.04.18-09:18:07) has a problem with presentation of new sensors. So I will have to sweat it until they fix that.
I compiled the gateway on Raspberry also with the beta version (after trying the stable version first), as it was mentioned that this could fix communication errors. No luck so far.
Bu this discussion of my problem should be on another forum branch.

@yveaux I'm not sure the issues is with the MySensors part. The gateway listens, but presenting a new node crashes Domoticz. After reboot I do see the new sensor and can receive and show updates, but the "new node" part is what bugs me now (I made a new node with atmega1284p which I want to add to my network)
I am using the beta version of the gateway & Domoticz

@yveaux indeed. It seems there is always some other thing to do first. Moving my desk was part of a greater reorganisation of desks and rooms. I set myself deadlines to be able to advance a little (next one is 16 May: lasercutting boxes at the FabLab), but still progress is slow.

The fact that my switch to version 2.2.0 on sensors and on ethernetgateway on Raspberry is not going well, also slows down progress. Step by step ...

I moved my desk to a new spot in the house and reoriented the desk. Still a mess, but that is how my mind seems to work these days: lots of stuff in parallel ...

@krisha
I use a 3V3 programmer. I also use standard pin headers, they fit without a problem.

@reinhold
Totally correct. Very dumb suggestion on my part. You would get 6V, which is above spec for the atmega328p and the nrf24

@reinhold
Glad you found the issue. I'm not sure there are 1616 batteries, but two on top of each other might fit ?

@reinhold
Something else I was thinking about. I did burn the boo loader before I mounted a NRF24L01+ board on my stamp size board.
I made another board recently and found that burning a boot loader while the radio is connected, gives me issues like the one you mention: sometimes an unexpected signature error, sometimes it starts and stop loading midway ... That was on a different board, but with basically the same connections between processor and radio.
So I think that you do need to load the boot loader before mounting the radio on the board. As for my newer board where I first found this issue, it was a robot control board I now need to redesign so that I can refresh the boot loader (ro anything else via ISP) with a mounted radio, by providing a "switch" of some kind to isolate the radio when I do not want it to interfere with the ISP loading.

@reinhold
Hi, the first thing I would check is to see if you can burn a boot loader on a standard 328P DIP format with the Nano. I'm not sure the ISP sketch, when running on a Nano matches the exact physical pins for MISO, MOSI and SCK. So check that.
I also burnt the boot loader with the sketch, but on a classic Arduino UNO as ISP. Never tried to do this from a Nano as ISP.

Fantastic booth, congrats for the Dream Team !!!

@sincze
The chicken shed was not my project, a compatriot did that. Basement flooding is very relevant to me

Sorry guys, will not be attending. I'm supporting my wife, she has exams to pass this week. Have fun !!! Looking forward to the pictures

@tbowmo

http://dirtypcbs.com/store/pcbs

After a lot of revisions, changes, corrections and doubting, I finally decided to commit to a first board production. We will see if this comes out good. The design is still untested. Just reporting on the progress (which is glacially slow).

@tbowmo said in 8Bit or 32Bit processors:

ATSAMD20E18A-AU

Too bad that MOUSER still charges me 20 EUR for transport, even for something as small as a single chip. I would need to buy for more then 50 EUR before transport cost is waived. How the suppliers on Aliexpress do it, I do not know.

@lafleur

I was wondering where you can get a M0 processor for less then the price of an atmega328p ? Most SAMD21's I see are 5 times the price of an atmega328p (normal given it's much better capacities).

I have been using version 1.8.x (at 1.8.2 now) for quite a while now, so no experience with 1.6.10

Best is indeed to update the IDE, as this will also bring new versions of GCC (the compiler) and I thought also of AVRDUDE (transfertool). Not sure about that last bit though.

Gert

@flopp

To use the FTDI connection:

You need a ceramic cap (not polarised).

RTS - CAP - RESET pin of ATMEGA

RESET pin needs a pull up resistor of 10K, connect as follows: VCC - 10K resistor - RESET pin of ATMEGA

@DavidZH
Do you also get these differences when compiling for both 16Mhz ? In this case one node is 16MHz (Moteino) and the second is 8MHz.
Apart from that I have no clue why this would result in different sizes.

@Samuel235
It also seems the nano is in a reset loop. I'm at work so I can not check my Mac for the fuse settings I use.

@Samuel235
If you are using a nano, what crystal is mounted on it ? Fast flashing indicates the processor is running faster then the expected 8MHz (expected by the timing routines of the bootloader). Could it be a 16MHz model ?
In that case you could try to upload a sketch at a higher speed: 76K8 baud.
Or you can try to load the bootloader for 16MHz/D13 (which in effect is the standard bootloader of an Arduino).

The boards .txt and platform.txt files are not complete yet, and I still need to check and change the pins_arduino.h boards for the 40 and 44 pin atmega's. That is still on my to do list, but the structure is there already. I'm still learning from other hardware deployments how to define this in a practical way. Hopefully by sharing this will be improved.

I have added my atmega328 directory in a RAR file and uploaded it to the site.

This compressed file contains a directory structure that contains all bootloaders I use, and the extra files needed to make most of those available from the Arduino IDE.

To use it:
Close the Arduino IDE
Unpack the RAR file
Open the IDE

This compressed file needs to be unpacked inside the "hardware" directory which sits inside the Arduino Sketches directory. If you do not have a "hardware" directory inside the Arduino Sketches directory, then you need to make this first.
Then go inside the "hardware" directory and there unpack the RAR file.

My directory structure looks like this:

[Arduino]
   [hardware]
      [atmega328p]
         [avr]
            [bootloaders]
               [myoptiboot]
                  ... all the HEX files ...
            [variants]
               [28PinBoard]
                  pins_arduino.h
               [32PinBoard]
                  pins_arduino.h
               [40PinBoard]
                  pins_arduino.h
               [44PinBoard]
                  pins_arduino.h
            boards.txt
            platform.txt

@Efflon

VCC pin is directly connected to the MCU.

The RAW or IN pin is connected to the regulator input. Th eregulator output is connected to VCC pin and thus to the MCU power input pin.

On a 3V3 promini you can give between 3V3 and 12V (on most promini's, some can handle up to 16V) on the RAW or IN pin. The regulator on the promini will bring that down to 3V3 (which you will be able to measure on the VCC pin).

By giving 3V3 on the VCC pin, some power is lost via the output pin of the regulator (through the regulator) towards the GND pin of the regulator. This should be minimal, but on bad regulators it can be enough to drain a battery in weeks. So yes, I would cut the regulator output line when giving power via VCC.

Cutting the line of the powerLED (on either side of it, doesn't matter) will make sure that the LED does not drain the battery either. This LED can pull between 5 -15mA depending on the protection resistor that sits in series with it.

So VCC pin and RAW pin are NOT the same.

@ErrK

Here is a library with power related modules and components. Have fun.

0_1484249208566_powermodules.lbr

@ErrK
I have something similar in my library. I will export it to a lib and upload when I get home tonight.

@Eawo
The reed switches need to sit between GND and D2 or D3 as you have connected.

The 1M pull up resistors need to connect between Vcc and D2 or D3.

This way D2 or D3 are electrically connected to Vcc when the switches are open (pulled high). When the switches close, D2 and D3 get connected to GND.

@alexsh1
Indeed, there is a solderpad near to the D2 pin which needs to be closed (connected) to allow the IRQ signal to go to D2, so one can use the radio

Always impressed by the quality of your designs @koresh !

@chaeron
Correct

@gloob

No, this board was not made for a specific housing. It just fits the dual AA(A) battery holders.

@bjacobt

It seems you are missing the capacitors connecting each side of the crystal to ground. Those should be between 15 and 25pf (depends on the crystal), normally ceramic type.

This one made it on the Adafruit blog:

https://blog.adafruit.com/2016/11/30/add-nrf2401-arduino-functionality-to-hacked-ikea-molgan-led-lamp-ikeausa/

Great Success Yveaux !!!

@Meshx86
The corrective value is needed every time you change a battery, AND if you need high accuracy.
On my battery based nodes I do not have a need for absolute accuracy, I just need to see the trend of the Vcc value.
Changing the battery happens every 12-24 months (depends on the use), so I'm not very interested in absolute accuracy. If you need real accurate measuring, I would suggest a real Analog-To_Digital chip.

@Meshx86
No problem to ask. I use the intern measurement method, which uses the internal 1.1V reference of the atmega328, so even if the Vcc value changes from 3.2V -> 2.6V, the reference will always be 1.1V, and the internal method allows you to calculate the actual measured battery voltage based on a difference with the reference, even with a declining value on Vcc (if powered by the same batteries).

@tlustoch
The node is a very simple one. So I never considered boot loaders, as the node would not need changing sketches during it's lifetime. I have boot loading functionality on my other designs, this one is a minimal board. Any extra chip would beat the purpose of the word "minimal".
It's a dumb node for a reason

@Meshx86
actually, you need a voltage divider if the voltage to be measured is above the maximum allowed by the processor at the speed you are running it.

If Vcc is 5V, then any voltage above 5V should be measured via a voltage divider.
If Vcc is 3.3V same principle, but you could get away with measuring 5V directly (would not kill the processor), but your values may be off.

@DavidZH
No particular reason, I did not spend as much effort in defining the options for the 32-pin package as I did for the 28-pin package.
When my free time becomes mine again, I will be able to take this up again. For now I have to be content with a relatively short online presence every week.

hi Ivo, very nice to see this on OpenHardware.io
Any chance you find the time to reverse engineer the Molgan board, or did someone already do that ? I would like to see a schematic of the original board, to recreate it with some additions.

@tlustoch
Not possible as there is no flash memory on the board. It was never the intention to update these nodes after their initial programming.

@tlustoch
Good point, will add that to version 1.2 (if I ever find the time :-))

@Carl-H
Those modules should be OK. Soldering this radio is indeed very tricky.

@Carl-H
Did you order the latest version of the slim board ? It has solderjumpers you need to use if you want the SCL/SDA pins connected.
If there is no solderbridge on either solderpad, the D2, SDA and SCL of the atmega are not connected. This board also requires the fuses of the atmega to be set to internal oscillator as there is no external crystal.

Can anyone share an EAGLE library for the RFM69HW and similar radios ? I'm looking for clear symbols and easily (hand) solderable footprints in an EAGLE 7.x library format.
If you have somthing similar for LORA radios, I'm also interested.

@NiklasO

Signing is not yet supported in the current Raspi Gateway.

@Carl-H
No, so far I have not experimented with OTA on this board or any of my boards.
Someone has used OTA on one of my other (batterybased) boards, because that one has an SPI Flash footprint.
When I get back to doing more MySensor stuff I will be experimenting with OTA. Being a Mac user my options are a bit limited now.

@NeverDie

It seems the collection of small MySensor nodes is growing
Nice work !

@Carl-H

The EEPROMs on this boards are of the I2C type and this is not supported by DualOptiboot, so unfortunatly you can not use OTA on this board.

OTA is only supported with SPI type flash memory.

I also do not have the sourcefiles for DualOptiboot to recompile it with my D8 LED flashing. At the moment I have to concentrate on other tasks at home, but recompiling DualOptiboot to my own desires is on my TODO list for this year (I hope).

@NeverDie

And making also the radio a detachable board would save you some board-space, thus reducing the cost again.

@sincze said:

Domoticx.com P1
Maybe the problem is that moving to certain pins is not allowed in the altsoftserial library.

Why is it "alt soft serial", when there is a "soft serial" library. Does the ALT version use interrupts ? Does it need certain comparator pins related to timers of the atmega328p ?

@marceloaqno
looking forward to upgrading my gateway to v2

@NeverDie
0.8 mm solder by STANNOL (HS10), packs of 100gr
The tip is around 0.8mm wide (narrowest tip I could get for my Weller station, I have an old EC2002)

@NeverDie

Check the datasheet for the atmega328p-au. It has a section on PCB layout.

I would go for same width as the actual pins, and make the pads long enough to have space for some solder (when doing it by hand).

On my stamp size node I also used the smd version and that layout was not difficult to solder when using a fine tip.

Here is a view of a node running exactly 1year. The effect of a bad radio is seen here as the fast voltage drops. I had a very low charged battery to start with, replaced it with new batteries which also discharged fast, and replaced both batteries and the radio. Since mid january 2016 the node has been running as expected. My guess is that this combo will run for 2 years (given how it has been working the past 9 months).

This node measures battery voltage, temperature and humidity and sends 3 messages about every 5 minutes.

And here is the battery measurement of the second node that went "online" the same day (18/sep/2015, with a good radio, and similarly used batteries from the start). This node sends very few messages (at least 1 every 24 hours, and when one of 3 contacts are opened). Most days it just sends 1 message.

So even with batteries already at a low level, you can make useful nodes using the MySensors setup

@TheoL
I will miss the mini maker faire as well (chillin in Ibiza at the moment, familytime)

@wergeld

No, the powerrails are not turned off, just the devices themselves.

5uA during sleep is about right. The 12.4mA during transmit is also normal, but the transmit time should be very short, so on average the total consumption of power will be low.

@vikasjee
Alex used the hardware described at the start of this thread.
You will find all design documents on Openhardware.io

@tbowmo
You can upload your files on OSHPark and share them, even if you do not order anything from them. As you use KiCad, the gerbers would be fine. They accept Eagle brd files as well.

@172pilot
I think you misunderstood my reaction. If the controller software is running on something else then an RPi, then what is the point of a second RPi running solely as a gateway ?
I combine bout functions in 1 RPi and I'm quite happy with it.
If my controller was installed on my NAS, then I would use an arduino based ethernet gateway, not an RPi with a nrf24 or rf69 as a gateway.

@TheoL

The 4cm sensor is nice to have some alarm under a washing machine for example, but in my "watertank" like problem (I have had up to 122cm of water in the basement) that would not tell me much.

The Ultrasonic sensor I use now also exists in a waterproof variant (as used in car-bumpers). Still need to experiment with that, as it would be nicer to use that in a watertank (is better protected against corrosion).

In my current setup, I expect the electronics to degrade after some time, since they are used in a very humid environment. The box all this is mounted in, is certainly NOT waterproof.

@Nca78

The reason I use the ultrasonic sensor is because I do not like to put a wire along the wall and a sensor on ground level. Now I only have a small case at cabinet level, with the US sensor directed to the floor. And I can measure any water level up to 255 cm with this.

A collegue of mine uses this same node to measure the amount of rainwater collected in his rainwater tank.

In Domoticz I have set up several triggers so that I get notifications on specific waterlevels. This is needed if waterlevels keep rising while the pump is working, meaning the pump can not handle the flooding and needs to be assisted by extra equipment.

@ericvdb

New version of sketch should solve the issue of powerlosses:

0_1472566354348_BasementAlarmUltrasonic.ino