Just for the fun of it I added some monitoring of the mailbox to my collection of MySensors items already in operation. I had no plans to show the project here because there are heaps of such displayed both here and there and the technological level is not much to talk about.

But then I thought it might serve as an illustation of what can easily be achieved due to the excellent work made by the MySensors team (many thank's for the job done...) because almost everything was already available. All needed was:

- A Sensebender Micro
- The SensebenderMicro sketch
- Two normally open reed switches 
- Adding two interrupts to the sketch plus
- A few other tweaks to adopt it to OpenHab

The reason for using the less common normally open switches was to save some battery juice. These switches are triggered almost all the time and every time the sketch wakes up a normally closed switch will draw a little current but the savings might be marginal, if any at all.

Here is the end result as shown by OpenHab:

Guess the titles are obvious even though displayed in Swedish but the (rough) translation is:

- Temperature
- Humidity
- Mail in
- Mail removed
- Battery mV
- Battery %

And this is what the installation looks like:

Just an observation, during a recent cold period with temperatures down to -25C the readings from this sensor were the most accurate ones. Other readings based on an 18B20 could be far off even though both sensors are in range at higher temperatures.

Have thought about adding a speaker function to say "Thank you, but please keep the bills" to see if this would trigger any reaction but so far have resisted the temptation

That's all.

This is a prototype for an energy pulse meter type sensor plus a Dallas temp sensor. Works after some problems with the radio communication so it is time to do a "real installation". A nano and radio is in the bigger white box, the DS18b20 in the small box and the pulse sensor is hooked up to the meter. The boxes and the IR sensor holder are made with a 3D printer.

The "Efficiency of Voltage Boosters" thread is full of useful info but has been sleeping for a year so this is an effort to bring it back to life again

I have built a few battery powered sensors based on the 328P-PU running at 8MHz as well as 1 MHz. Batteries used are common NiMH size AA + cheap Chinese 3.3V step-up converters. Both the processor and the radio are powered from the 3.3V converter which I understand can be a bad practice. Still I decided to try because I did not want to tamper with the fuses/bootloader at this stage and luckily I have so far not experienced any of the here described connectivity problems.

More or less out of curiosity I made a few tests of this setup using different sizes of same brand electrolytic capacitors (nothing fancy, bought as a Velleman high-Q kit, labeled "made in Europe"). The results does not give more info than already available here but it helped me understand and hopefully can help others too.

For the test setup a 10µF is soldered to the radio pins and I can add another in parallel through a socket. The unit tested is also equipped with both a 3.3 and a 5V step-up. A photo of the setup as well as a few screen dumps from an oscilloscope are attached as a pdf (hope it works). Readings are taken using a 8 MHz chip programmed as a motion sensor and while the sensor is at rest.

0_1462995658167_Tst.pdf

Here is a short summary and a curve of same data:

10 µf dV 76 mV
10 + 22 µF dV 43 mV
10 + 47 µF dV 28 mV
10 + 100 µF dV 14 mV
10 + 220 µF dV 9 mV
10 + 470 µF dV 5 mV

A bigger capacitor of course lower the amplitude of the ripple (not unexpected :-)) and the rapidly falling curve shows that the current recommendation of 47 µF is a good choice. Adding more will lower the ripple but not at all proportionally.

I am not experienced neither in building these battery powered sensors nor in measuring them why any comments/corrections will be appreciated.

I wanted to fix an automatic/manual control for a couple of awnings. Most of such projects are based on 220 volts motors and quite expensive parts so I decided to try to make a "poor mans version". This is the first test version based on:

12V power supply.
An Arduino Nano with MySensors stuff.
One "Genuine Chinese" 12V DC motor with gearbox.
A L298N Dual H Bridge for motor control.
An ACS712ELC-5A to measure the current.
A couple of door/window reed type switches.
A few 3D printed boxes, one magnet holder etc.
Buttons etc.

The function desired is quite simple:

Manual control from Openhab or buttons on the control box.
Auto control based on light level reported from a Z-wave based light sensor.
The buttons can control the motor directly or via commands to Openhab .
Basic movements are "down to the down endstop" and "up to the up endstop".
The movement can also be manually stopped anywhere from Openhab or the buttons.
To avoid motor overload the current is measured.

Here is the original, always working solution:

And here is the dc-motor version (a test installation):

Parts needed:

The control box, a bit crowded but everything works:

The dc-motor adaptation:

The Openhab page (won't translate it, sure you get the idea):

The basic idea is working, control logic works but auto mode and stop due to current overload are not implemented yet. Also this motor will not be sufficient for everyday use but a more powerful unit is ordered. As 12V motor vinches are available up to sizes for 4 wheel trucks this should not be any limiting factor. Question is just to find something of smaller size but still working.

As such a project involves several unique parts a 3D printer is of great help. To be able to design something, print it, make a test and modify whatever needed is a lot of fun in addition to fixing the electronic parts and the programming.

All is hopefully installed and working before spring is here.

It is fall season, time to move inside and build sensors. So far a wind/temp/humidity and a rain gauge have been added to the collection and this post describes the latter.

This first edition is based on the Misol type and I decided to write a simple piece of code to support that. Because it had to be a battery powered node which sleeps most of the time the natural choice was to base the code around the MySensors sleep function. The combined functionality of event triggered and time triggered interrupt is ideal for the purpose.

To simplify things I am only interested in the daily amount of rain why I reset to zero mm rain at midnight. I prefer to keep the code as simple as possible at the sensor level because other values are much easier to calculate at the controller level, at least when using OpenHab and its rule engine. I have no idea about the capabilities of other controllers.

Unfortunately I also wanted to receive messages from the controller. Those are for remaining runtime to midnight as well as being able to send zero or last known reading at any start/restart. This of course is a complication because of a mainly sleeping sensor.

So the sensor has to function without the normal timer functions. The first approach is instead to use the wake up events from sleep as a timer and keep track of time for remaining cycles to midnight. Also at any sending of amount of rain to the controller there is a short wait to enable incoming messages before going to sleep again.

The challenge (at least for me :-)) was to establish when midnight occurs without using any standard timer functions and without asking the controller at every end of the cycle. Because of how the rrd4j persistance works in Openhab the cycle time need to be max 60 seconds so there are quite a few cycles each day.

After several versions the approach became kind of an iteration where the sensor checks the remaining time at half the estimated runtime, then asks again at half of the newly found remaining time and so on. Most likely there are much more elegant ways to accomplish this but it is working.

The sensor itself is "homemade" based on the 328P-PU which runs at 1 Mhz. The only hardware complication was that I found the signal from the Miso unit to be very bouncing why I added an inverted Schmitt trigger to get a nice signal, simply because I had a few lying around and the use of capacitors only still gave a peculiar reading.

The sensor box is a standard "waterproof" IP65 junction box and the mounting console was made with my 3D printer. A few pictures can be found below.

One peculiarity with this sensor was that when using the MySensors library v2 it runs fine at 1MHz but, with everything else identical, modifying the chip to 8 MHz causes the radio connect process to fail. When going back to 1 MHz all runs well again. I have not digged any further into why this is happening.

PS. I have also printed the stl's designed by BulldogLowell as well (@BulldogLowell - Thank's a lot for sharing) but not yet finished that assembly. There are a few modifications I wish to make and not yet had time to finish but this is an issue for another thread.

I decided to test the change from the old (v 1.4 and 1.5) MQTT Gateway (broker) to the new gateway which is a MQTT client. I use Openhab (on a RPi) as controller and must say that the old MQTT gateway has been working fine all the time so the change was triggered mostly because the current gateway is stated to be obsolete for the next MySensors release.

This is just a brief summary the experience so far:

As I had a couple of Nodemcu ESP8266 and no W5100 laying around, the natural choice was to test the ESP8266MQTTClientGateway from the development branch. This is a client why also a broker must be installed, in my case Mosquitto on the Openhab RPi system.

The ESP8266 installation was painless. It worked more or less "out of the box" after a couple of small compilation errors due to choosing DHCP. These were easily eliminated and I also switched to using a fixed IP anyhow.

Mosquitto became a hassle. Everything seemed to be working, I could subscribe/publish messages which were visible over the network but Mosquitto refused to accept connections from the ESP8266 but worked fine for other connections. I tried to change MQTT version as well as other things but without luck. For the install I used the Mosquitto Wheezy repository to get the latest version but something was clearly wrong.

Did bite the tongue and made a completely fresh Raspbian installation based on the Jessie version (was on the list anyhow), a fresh Openhab installation and a Mosquitto from the Raspbian Jessie repository. Believe it or not, Mosquitto started to work as it should.

Then Openhab became the nightmare (I am not exaggerating). First I made a mistake with not observing that the MySensors version of the MQTT topic had changed quite a bit from v1.5. My own fault.

Anyhow, this means that Openhab item definitions have to be adjusted to the new topic structure (not a big job, "find and replace" in a good editor does it swiftly).

Once the items were OK I hoped for success but that was in vain. The MQTT messages from/to the gateway via Mosquitto were completely ignored by Openhab even though the connection to Mosquitto was accepted and established with no error loggings at all.

Of course I tried the old binding to the version 1.5 gateway again and this worked like a charm. I made some test items in Openhab and tested bindings to Mosquitto on the RPi and Mosquitto on Windows and found that Openhab showed outbound commands for these test items on the bus and also sent them to the broker but refused to read anything coming in.

The bindings used were of the transport configuration type which had worked well for the v1.5 gateway. After many hours of work and as a last resort I decided to test adding an event bus binding configuration to the Mosquitto broker definitions in Openhab. And even if I had made an error in the topic definitions the MQTT messages STARTED ROLLING IN!!!!!

So just by adding a stateSubscribeTopic and a commandSubscribeTopic in an event bus configuration Openhab seemed to have loaded up what was missing. This was never needed for the binding to the v1.5 MQTT gateway and there is no logic in why it made a difference for the Mosquitto binding. Especially so because the topic definitions I made for the new binding were wrong.

Now the ESP8266 test installation has worked without glitches for a day and the messages keep rolling in to Openhab. State changes as well as commands sent back to the sensor boxes via the ESP8266 gateway works fine as well.

And I am keeping my fingers crossed.

I assume I am not the only one using Openhab and the v1.4 - v1.5 MQTT Gateway and hope this might give some info to the "topic" of changing the gateway.

More for the fun of it I bought a Pi Zero for testing purposes but found no really good case for the v1.3 model so I made one using the 3D printer. If anybody is interested the stl's are here:

http://www.thingiverse.com/thing:1684115

I have no clue where this post really belongs so I put it here under "General" and tagged it with 3d print.

@hek @tbowmo Thanks! Cut the radio IRQ pin and soldered a connection to D2. Tested to attach both interrupts and it works using a modified SenseBenderMicro sketch. "The Thing" will when ready be placed in my mailbox (which has mail-in and mail-out doors) and as a bonus report the outside temp, humidity and battery status. Does not solve any of this worlds biggest problems but it is fun

I tried using the "original" sensor sketch with Mqtt and Openhab and the sensor receives no answer to the request for a pulsecount startup value. Exactly as you describe.

I found one way to bypass this problem. Maybe not the most elegant but it works. I used V_VAR2 to send the request for the startup value, picked this up with an item in Openhab and made a rule which did send back a startup pulsecount using V_VAR1 as the sensor sketch expects. Thus the change to the code is very small.

Another way (the rude version) is to set the pulsecount to 0 in the sensor sketch and comment out the code part requesting the value when no count received i e this part

else if (sendTime && !pcReceived) {
// No count received. Try requesting it again
gw.request(CHILD_ID, V_VAR1);
}

It is not nice but after a few hickups the sensor starts working

Now the RPi based on a new install of Raspbian Jessie, OpenHab 1.8.0 and Mosquitto is up and running and the ESP8266 MQTT client does connect without any problems. I have not changed anything in the code but Mosquitto is now based on the RPi repository for Jessie and not the mosquito_wheezy one. That seems to have fixed it so those versions are likely different but I have not put any time into checking this.

@marcossu Podría buscar el siguiente texto a través de Google: illuminate steps when people walk the stairs
Aquí hay un ejemplo: www.instructables.com/id/Motion-Activated-Stairs/ pero hay varios.

But as Yveax already has said - this is an English speaking forum so please use this language.

@bjacobse With two extruders you load up each with your most common filaments and thus do a filament change less frequent. Then it is a "nice-to-have" but nothing cruicial at least not for me who rarely combine materials in same print.

In more advanced use when people want to print for example support structures in one material and the item itself with another filament this is not practically possible with less than two extruders.

Changing colors can be done with one extruder but frequent changes for same part are of course a pain.

So depending on use the dual (or even more complex) extruders are everything from just nice to a must. For a beginner it is not needed (and for something "home built" it is most likely possible to change to a more complex extruder after some years).

@bjacobse Dual hotends are quite nice to have. I often have ABS going to one of them and PETG to the other. I do not use this to change colors during printing (actually have just tested it a couple of times) but being able to slice for extruder 1 or 2 means that I often can print without changing the plastic because my most common choices are those two qualities.

@skywatch Thank yo so much.

@cyberthom Thank you for the comment. No, I have not published the model anywhere and mainly because I do not have the time to support others trying to build it.

Like with any other big 3d-model like this it is also hard to guarantee that all small changes are incorporated into the model. Also, to build the various parts a fairly good 3D printer is needed (all plastic parts are made of ABS using roughly 100 degC bed heating).

@pihome Sorry I missed the little word "smd". It is of course possible to use a soldering station also but is not always so simple. I have used the butane driven Dremel soldering tool mainly because I have nothing else. It is not easy to control the heat with that one.

When I started with 3D printing quite a few years ago I bought an Ord Bot Hadron frame and then assembled the electronics from bits and pieces bought here and there. The printing table is 200 x 200 mm and the useful height is somewhat less but it has all functions needed. During this assembly process and years thereafter of printing I learned a lot and when the Ord Bot started to feel a bit small I began thinking about something bigger.

So I designed from scratch a much bigger one (printing volume 450 x 450 x 500, footprint about 700 x 700 mm, two extruders and a 220V heated bed) based on the CoreXY principle and this became a really good printer which has been working well for a couple of years now. All plastic parts were printed on the Ord Bot (I attach a screen dump from the 3D design model for info)

So my advise is much along the lines as mentioned by @skywatch - if you have the skills, time and facilities build one yourself. You will never regret it (except for during some memorable events during the process ).

If building one yourself is out of the question do not look for the cheapest options. It will just take a few prints before realizing that a heated bed is needed, that more advanced software is a must, that network connectivity would be nice etc. etc. Well known brands like a Prusa I3 is a good choice but there are cheaper options (clones) out there as well but do not expect getting much or any at all support for the cheaper stuff.

The best one I ever used is a Weller WS81. Heats up in a few seconds and even if the unit itself is a bit expensive the spare soldering tips are dirt cheap (even the originals). With a power of 80W it can be used for quite big stuff too.

@masmat Also I use the "native" OpenHab MQTT binding (my version is 1.11.0) and it works really well with OpenHab 2.2 but , as @bgunnarb says, it is a manual procedure to define the items.

I have not tested the MySensors OpenHab binding because I have a number of sensors of own design which I guess will need quite a bit of redesign to fit into this picture, if at all possible without modification of the binding.

I have not tried the Pi as a gateway so cannot comment on your second question, unfortunately. As the Arduinos and ESP work well as gateways and my Pi already serves OpenHab and Mosquitto I will keep it that way.

As mentioned there is an OpenHab binding you can take a look at.

I started using OpenHab long before this binding was available so my setup is to use the OpenHab MQTT binding.

Technically it is quite simple, you seem to have all what is needed. OpenHab and Mosquitto can run on the RPi and a MySensors MQTT gateway sends the sensor messages to Mosquitto over your network. The Mosquitto passes all messages on to OpenHab.

Now my gateway is based on WiFi using a Wemos Mini or other ESP based board. I have also used an Ethernet MQTT gateway without any problems.

At the OpenHab side you need to create Items which listen to the MQTT messages and then the OpeHab rules can act on these messages and display results using the OpenHab sitemaps.

There is a lot of info available about how to set all this up so Google plus MySensors and OpenHab docs/forums will give you the details needed.

This rough description outlines one "manual" way of connecting to OpenHab. Also the serial gateway can be used but I think MQTT is the best option. I presume that the mentioned binding can simplify things but I have no experience of that approach.