Best posts made by mbj

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 started building various sensors and control functions based on Mysensors quite a few years ago. Some I use originate from the solutions published at the build sections, others are of own design. At that time very few affordable off-the-shelf products were available.

My main controller is OpenHab and MySensors data are sent/received using MQTT. The other part of my IoT network is based on Z-Wave and once getting this mixture to work it just runs with very few hiccups. Main problems are nearly always associated with upgrading to new software versions, especially OpenHab has taken lots of time during conversions.

So for the moment I have everything I need running, it runs very stable and is in a "maintenance" state. Time is limited so focus and activity has had to shift to other things but I try to follow the forum.

For me Mysensors has been a great experience and I will continue using it if other similar sensors/functions are needed. I like building the Mysensors items myself and will not choose anything else if an own project can succeed.

With heaps of IoT things and systems available off the shelf to reasonable prices I think MySensors has to focus on robustness, simplicity and good guides so enthusiasts being tired of the complexity and non-compatibility of commercial solutions are willing to dig out the soldering iron and learn how to make own things.

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

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.

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

@hek That was very visible, please excuse my ignorance. Even though I have looked at this page I managed to leave the change unnoticed.

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.

Right now the gateway is located inside and upstairs towards the far end of the house in relation to the mailbox (25 - 30m) . So to make the mailbox work without any long range radio I had to add a repeater to a room facing the mailbox. This repeater was useful for other things as well (could switch some long range radios to the normal ones) so I felt OK to install yet another little power consumer.

Just a (very) minor thing. I noticed during conversion to v2 of a sketch based on the SensebenderMicro sketch that the sentence below does not conform to the logic between message types and presentation:

#ifdef BATT_SENSOR
gw.present(BATT_SENSOR, S_POWER);
#endif

but the message is defined as:

MyMessage msgBatt(BATT_SENSOR, V_VOLTAGE)

As S_POWER reference V_WATT and V_KWH presumably the S_POWER should be changed to S_MULTIMETER as this is the only item which refer to V_VOLTAGE. Or maybe another S type item is needed??

I am using OpenHab which ignores all these presentation items so I am not aware of how they actually work with a controller that uses them.

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.

@Newzwaver If you Google on this subject you will find threads like this one which may help you understand the issue: http://forum.arduino.cc/index.php?topic=16731.0

Basically I think the answer is that if you already have the electronics to read the signal from the PT1000 and can communicate that to a Mysensors sensor it should be fairly easy. If you have to build it all by yourself it is a bit more work to do like the thread above shows.

On the other hand, buying a few DS18B20 is dirt cheap and and then everything you need is already available. They come in waterproof versions as well if you feel you need this. One example from Ebay is http://www.ebay.com/itm/NEW-Waterproof-Digital-Thermal-Probe-or-Sensor-DS18B20-Length-1M-/172243763999?hash=item281a87431f:g:Lj8AAOSw3YNXYu7h

Finally I have the ESP8266 gateway running with Mosquitto and Openhab. Because the ESP8266 Gateway installation was painless and Mosquitto and Openhab the major problems I have posted some general info at this link in case anyone is interested, see http://forum.mysensors.org/topic/3005/switching-from-v1-5-mqtt-gateway-to-esp8266-mqtt-client-gateway.
(Sorry if this is the wrong procedure but found no way to add other tags to a message in this thread).

@gadu Sounds interesting. May try this solution sometime but of course it is another thing to learn. I am currently struggling to find info and learn about Openhab as well as Mysensors as well as MQTT as well as ...... :-). Open source stuff is not always well documented.

I started with a small MySensors project more than 4 years ago and life was easy then The choices were few and I felt they were well documented.

I began with an Ethernet gateway but moved to MQTT (ESP8266 because of WiFi) once it was available. The choice of radio was easy and even if there were problems most could be solved. I still run 10 - 15 items using NRF over MQTT to OpenHab and also have quite a few Z-wave items connected to this system.

Today there are heaps of choices and the development continues but my feeling is that MySensors is still mainly driven by a small community of enthusiasts working on this on their very limited free time. As more and more functions/variations are added the complexity grows and the need for correct documentation increases exponentially but the resources are not at all growing in same pace.

I have some experience with using much larger projects (OpenHab, ArduPilot, PX4 etc.) and and also here documentation often is a mixture of updated and outdated info. Many times the forums are where the correct answers can be found but very often there are many erroneous answers per one correct one.

For a project like MySensors I am convinced that the only way to go is to select an entry level configuration with few well working choices which are always kept alive and up to date.

As users become more and more experienced they will have come across a lot of useful info as well as have learnt how to find more. Hopefully some find documentation so important that they are willing to contribute also.

For the advanced stuff of course there should be an ambition to document it well and keep it actual but why not accept this as playground for the advanced users who know enough to find the answers as well as are able to assist others.

Last but not least. We always get what we pay for, don't we To keep a full blown MySensors activity well documented will cost a fortune and require very up scaled resources.

Cheers
Mats