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 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

@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.

I am using OpenHab through MQTT and it is so that the controller has no builtin functionality to respond to the startup message from the sensor. I had to make an own startup message to be picked up at the conroller and then use a rule to send the old pulsecount back at at startup.

There should be several discussions at the forum about this so the info is here somewhere.

@pjr I guess the trick is to find a closed loop belt of suitable length and also make a screw design which can move enough sideways to tighten the belt.

@dbemowsk For Z I have seen solutions with motors and belts so this is possible. It is just another piece to design and the motor need to be sized for both which might be a bigger problem with Y than with Z. I have never thought about it so it is just a guess.

@gohan The beauty with a CoreXY is that both X and Y movements are handled by stationary motors which do not add any moving weight. Changing to lead screws means that most likely 2 motors are needed for Y (for a large design) and then another screw and motor for X and these will add to the moving weight. Of course a belt could also be used for X but the motor arrangement needed for this will still be a moving part.

Even if my CoreXY is really big it can print with same or even better resolution than my old OrdBot Hadron which is so much smaller. The OrdBot has a direct drive extruder and also the X motor arrangement attached as a moving parts and this affects what printing speeds can be achieved at a given resolution. The CoreXY has a Bowden arrangement which further lowers the moving weight.

@gohan If we are talking about hobby stuff with comparable low cost the belt should be better but there are limitations like how much weight can be handled at high speeds without loosing precision. So it is a question with many answers depending on the circumstances.

@davidzh A change to 1.8.5 did not help. But disabling My_Debug still works so the problem is not critical.
For the sake of clarity I have also tested with an unmodified Sensebender sketch and also this one gets compilation errors when enabling My_Debug. So the problem comes from the implementation of the debug code.

@dbemowsk Yes it is a Ramps but in a way it is only "partly" used. The bed heating is, as mentioned, at 220V so Ramps is only used for the signal an external device. Same with the extruder heaters, i e the Ramps is used for a signal to a more robust device. This remedies some of the weaknesses of the Ramps card and enables heating of two extruders simultaneously.

I have bought external drivers for the step motors as well but not yet found any reason to switch to these. So the motors are still driven by the 8225 drivers on the Ramps card.

In case anyone is interested, this is what "the Thing" looks like on the drawing board:

Presumably the Mysensors forum is not intended for discussions about 3D printers why I hope I have not violated any rules by jumping into the conversation.

@davidzh Do not know what is going on with my browser, I have replied to your question but cannot see this reply anywhere. Also i did not receive any notification about your question so my reply is late, sorry.
The issue showed up when compiling for library version 2.2 on Arduino 1.6.12. I will test with the latest version as you suggest, thank's a lot for the info.

I have had an OrdBot Hadron for quite a few years now and it has been serving me well except for one thing - the size 200x200 as well as height are sometimes a limiting factor and especially so since most heated beds are much colder towards the edges.

So I decided to design and build a bigger CoreXY which is up and running now with a print size of rougly 450x450x500 mm. It is equipped with double E3D Bowden extruders and a 220V silicon heater for the alu printing bed.

The whole process was of course time (and cost) consuming but it was really fun and a great experience.

One essential aspect of all printing is to be able to keep the print volume warm to minimize warping etc. This means that the print volume should be enclosed and especially so when printing ABS and some others.

I have a somewhat modified sketch based on the Sensebender Micro sketch and this one failed to compile when changing to the v2.2 library. So I copied the original sketch from the homepage and also this one fails to compile when enabling MY_DEBUG. The error messages are numerous so it is pointless to add them here but a couple of examples are:

\Arduino\libraries\MySensors-master-v220_180209/core/MyOTAFirmwareUpdate.cpp:63:41: error: expected ')' before 'PRIX16'

OTA_DEBUG(PSTR("OTA:FRQ:FW REQ,T=%04" PRIX16 ",V=%04" PRIX16 ",B=%04" PRIX16 "\n"),

\Arduino\libraries\MySensors-master-v220_180209/MyConfig.h:1815:43: note: in definition of macro 'DEBUG_OUTPUT'

#define DEBUG_OUTPUT(x,...) hwDebugPrint(x, ##VA_ARGS) //!< debug

\Arduino\libraries\MySensors-master-v220_180209/core/MyOTAFirmwareUpdate.cpp:63:3: note: in expansion of macro 'OTA_DEBUG'

OTA_DEBUG(PSTR("OTA:FRQ:FW REQ,T=%04" PRIX16 ",V=%04" PRIX16 ",B=%04" PRIX16 "\n"),

As this is in the core code it is something I am unable to figure out myself, unfortunately. But as the compilation runs through without problems when disabling MY_DEBUG it is not any mayor issue until the debug output is needed.

@jumping Unfortunately I had no time to look at anything last week and i will not be able to do it the next cople of weeks because of travelling but I promise it will come. I assume that you also have seen the code for a rain sensor at the Mysensors forum but if not take a look there in the meantime. I know this is a different solution but might be of interest anyhow.

@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

@Mark-Swift
I have not looked at the code for nearly a year so have no idea if it is usable or not for anybody else. Right now I have no time to take a look at it but will dig it out as soon as I get a chance, hopefully within the coming week.

@Carywin
That is an alternative way of doing it, and also much simpler to code and also good enough for a rain sensor. It seems I always tend to complicate things so I have tried to design this type of functionality (with counters and alike) to be inside the sensors because if the controller (here OpenHab) is down for any reason the sensor lives its own life and once everything is up again the sensor can report a correct value. I have the same type of functionality for the energy meter sensor which is based on the MySensors Energy Meter.

If the sensor has been down it can receive last known value from OpenHab with an incoming message but any readings while down are of course lost. Also a manual set value can be received.

Does it make any sense?

@sundberg84 Thanks. The item is an inverted Schmitt trigger used to get a clean signal. What came from the reed relay was awfully bouncy so readings were not consistent.

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.

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.

@TXSpazz This difference depends on what version you are using. For version 2 it is Mysensors.h . Earlier versions used Mysensor.h.

It was not so hard finding one. I got it from the Pi Hut because now and then they get a shipment and via their newsletter the word is spread. Actually, they seem to have it in stock right now. Just pick the "Just the Pi Zero" option to avoid all their extras

Here is the link https://thepihut.com/products/raspberry-pi-zero?variant=14062715972

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.

@NickBuilder
I now have looked at the code and (of course) you are right, the interrupt is used for the pulse count which I think is the best way of programming this function.

My sensor is based on an old version of this code but modified for use with Openhab (which does not give any start value back, this function has to be own programmed). Another modification is that same unit monitors a number of temperature sensors.

The "thing" has been in operation since my first post above and works well but I guess I should make an effort to modernize the code. Maybe a task for the long and dull autumn/winter days here.

@NickBuilder
I made this one so long ago that I do not remember the program well but (from a bad memory as well ) I think that the interrupt is there for the sleep mode only which is optional and meant for a battery powered sensor.
Mine is on USB power all the time so I do not use the sleep mode at all and besides I want to follow the watt numbers which will not be available during a sleep mode operation.

In principle there should be no problem using two interrupts but the program need a rewrite for that setup of course. Also it might be questionable if using sleep mode together with two power sensor leds will save anything at all (often they blink 1000 times per kW consumed).

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.

@DirkB19 Think you will get another advantage by changing as well - must be a lot easier to monitor the MQTT messages when topic clearly shows the difference.

@martinhjelmare
Thank's for the explanation which follows what is my own understanding of the MQTT setup and procedures.

When defining items in Openhab obviously there is no problem handling both publish and subscribe topics.

@DirkB19
I have not looked into what happens when using same prefix so this is just an unconfirmed thought:

The MQTT broker relays any message received to anybody listening. So when using same prefix for publish and subscribe there ought to be a risk that your gateway reads and forwards to the sending node same message which it just did send.

Many nodes do not read incoming messages and then this does not matter but for nodes reading incoming messages then there might be some issues if , for example, the outgoing message being interpreted as an incoming setpoint.

Would be interesting to hear if anybody knowing the details could comment on this.

I have at least one node running with DHT22 and the code from the development branch and without any problems. Just one thought - this code is using a different DHT library compared to the v1.5 version if I remember right. Nothing you have overlooked there?

@DirkB19 Hi Dirk,
Looking at this link http://forum.mysensors.org/topic/2352/guide-setting-up-and-testing-mqtt-client-gateway you will find the new topic to be MY_MQTT_PUBLISH_TOPIC_PREFIX/FROM-NODE-ID/SENSOR-ID/CMD-TYPE/ACK-FLAG/SUB-TYPE . Thus the difference is the added /CMD-TYPE/ACK-FLAG/ plus that the V_XXXX is changed to the corresponding number. So to me your item 1 change looks perfectly OK.

Your item 2 is a bit unclear to me and these are of course dependent on your definitions in the sketch. I did use the preset data so my incoming to Openhab typically looks like:

{mqtt="<[mosq1:mygateway1-out/22/1/1/0/25:state:default]"}

And the outgoing (in this case a command) :

{mqtt=">[mosq1:mygateway1-in/27/1/1/0/24:command:*:default]"}

The in- and outgoing need a different definition (mygateway-out versus mygateway-in in these examples) as far as I can understand from the publish/subscribe logic in MQTT.

Hope it makes sense.

@DirkB19 The Arduino pinouts are, to say the least, confusing and it helps to look at one of the pinout sketches you can find on the net, for example http://marcusjenkins.com/wp-content/uploads/2014/06/ARDUINO_V2.png. So the pins are, as Martin said, (A0-A2) which must be exactly as you had them wired before if you had a "previous version" working MQTT Ethernet gateway. I have such a gateway (nowadays used as a spare) but built with a nano and a W5100 unit and it compiled and worked right away using the GatewayW5100MQTTClient.ino sketch from the development branch.

As you see nothing in the serial monitor there must be something else. Even if you upload the sketch to a completely barebone UNO without radio or anything else attached you will get a message in the serial monitor, in this case:

0;255;3;0;9;Starting gateway (RNNGA-, 2.0.0-beta)
0;255;3;0;9;Radio init failed. Check wiring.

So if you see nothing at all there is something really basic wrong.
Presumably your sketch compiles OK so I assume you have exchanged all Arduino libraries to the libraries which belong to the Mysensors development branch.

@DirkB19

It is looking like this, just uncomment the #define - line:

// W5100 Ethernet module SPI enable (optional if using a shield/module that manages SPI_EN signal)
//#define MY_W5100_SPI_EN 4

@DirkB19 If you do not see anything in the serial monitor for the gateway then the problem must be with the gateway itself. Have you observed that there is a special #define MY_W5100_SPI_EN to uncomment when compiling for an Uno with the shield installed ? If not, you can try that.

@Masonkante Another alternative is to build your own using a 328P-PU chip. This is at least a lot more fun and the only thing needed is the chip itself (almost).

@Masonkante With the nano you have power regulators and other stuff involved as well. Also you will get a poor battery life using that one if it is not modified a lot. Have you looked at this?
https://www.mysensors.org/build/battery

@George-Whitehouse Good you have it working. Seemed that your sketch was working OK as the messages in the serial monitor were all marked ok.

I have seen that even if sending of messages work receiving them may fail. In such a case the serial monitor of the gateway ought to show a "fail" in the log so when having problems it is always a good idea to monitor the gateway traffic as well.

I am using the new MQTT client and then it is easy to monitor the MQTT messages as well (as you showed in the first post). This has simplified looking for errors a lot, at least for me.

@Masonkante So far I have only one battery powered node, the Sensebender Micro. I do not remember seeing any varying readings when connected to the programmer but this node is powered from programmer only during programming.
So I do not have much experience from running it on power from a FDTI programmer.

You mentioned first that your node is a nano so it is a bit unclear to me if you refer to a Sensebender or a nano.

@mbj said:

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).

Do not know if this info is of any interest but my ESP8266 MQTT gateway (based on a NodeMCU board) has been running without hiccups for almost a month now. So it has been very stable. I have also made a very short test using a Wemos D1 Mini for the gateway and this one seemed to be working as expected as well (not very surprised but you never know until it has been tested :-)).

@George-Whitehouse What do you see in your Openhab event.log. If your TestGD switch is defined OK in your sitemap you should find any changes to the switch logged as events for the TestGD item in the event.log (maybe a stupid question but since you apparently have no incoming messages logged in the serial monitor the question is "what have you sent"/"have you sent anything at all").

@Matt-Pitts A very small simplification - in your first rule have you tried:

if (hall_motion_raw.state == 1) sendCommand(Toggle_2,ON)

I am not sure if it works but hall_motion-raw.state is a number so I think it should but it is always hard to predict how Openhab item states works in rules. I hate all these conversions like "as Decimaltype" needed in many places.

How simple the rules can be made depends also on the settings of your sensor. My motion sensor (z-wave) sends ON when triggered and OFF after a set time after untriggered. So the rules become really simple.

Without knowing how your sensor type and setup thus it is hard to comment much. From reading about the most common type of sensor it seems that If it has the jumper set to retriggering then the signal stays on until motion is no longer detected while set to non-retriggering the signal varies on/off as triggered. If your sensor works the "retriggering" way the rule for "hallLigtOff" may work with something like:

rule "hallLightOff"
when
Item hall_motion_raw changed
then
if(hall_motion_raw.state ==0) sendCommand(Toggle_2,OFF)
end

Sorry for not being entirely sure about how this sensor works but I have not used it or experimented with it. I need to try it some day.

UPDATE: I tested one of these sensors today (referring to settings described here http://www.mysensors.org/build/motion) :

Jumper set to "auto reset"- sketch sends 1 and then a 0 comes when there is no motion and timer runs out.
Jumper set to "no reset" - sketch sends 1 and then 0 comes after timer has run out, if motion still detected a 1 is sent again followed by a 0 when timer runs out and so on. So as long as motion is detected this goes on over and over again.

When using "auto-reset" the rule above ought to work (if the "DecimalType conversion can be deleted, otherwise with this added)

@Matt-Pitts First obvious thing is that the line "counter = counter +1" now placed after "when" should be placed after "then".
Also your item, "hall-motion" is a number and defined as "state" and you check for "ON" or "OFF" in the rule. I doubt you can get these things to match because using "ON -OFF" would belong to a switch in Openhab (or do you send for example 0 and 1 and map these to ON/OFF maybe ?)

I have not tried to figure out the "hallightoff" rule but for example the line "sendCommand(hall_motion,OFF" is a command which i guess should be sent to the sensor to set the "hall-motion" to off but your definition of "hall-motion" is (as above) a number and a state change (But maybe the mapping could work in that direction too, I have never tried it. Actually I do no not understand why this is needed, thought a motion sensor turns off by itself and that the logic should be to send that change from the sensor. But I have not used these with Arduino so have not thought about that. My motion sensor is on z-wave).

Hope this can help you somewhat.

Correction - I should have looked at the motion sketch before answering. It sends 0 and 1 so pls disregard that comment, The number will work to pick it up.

@Masonkante I could not make it work with MySensors v1.5, Openhab and the Sensebender sketch because (as you have noticed) battery level is an internal message. I had to make a custom message but this is easily made so it is not much of a drawback. I wanted a message for the actual level in mV as well so it did not matter much.

@joseraj Yes, the V_VAR2 solution works well. I have used it for a long time. Of course it is possible to modify the sketch so that no request for a start value is made and always start at 0. But I like the idea of getting a start value from the controller when it is needed to restart the node.

@George-Whitehouse There are pin-outs listed in the GatewayW5100MQTTClient.ino sketch. If I remember right these and up identical to what is used for a W5100 Ethernet gateway but pls check. Just remember to install the full libraries from the development branch, will not compile at all using 1.5 libs.

@joseraj I thought I could eliminate using the V_VAR2 startup because of the new MQTT format from the development branch gateways has the MySensors command type included. In theory this might work as a replacement for the V_VAR2 message and the sketch could be used without modifications.

Could not make it work though because the gw.request message is sent without payload which Openhab just discards with an error message.

So it looks like the start up when using Openhab will need the extra message and the rule.

If you are interested there is some more info here http://forum.mysensors.org/topic/825/need-help-with-pulse-counter-for-power-meter/11

@George-Whitehouse The MQTT gateway from the current 1.5 master branch is a MQTT broker which will be obsolete in the next version of the software. Should work on an UNO, I have used it on a Nano without problems. Maybe not a good idea to start using something that will disappear.

Under the development branch you will find two MQTT clients, one based on Arduino and Ethernet (should work on an UNO, again I have tested it only on a Nano) and the other one is based on ESP8266. These two will be supported in the future it seems. Both are MQTT clients and need to talk to a broker. I currently use the the ESP8266 gateway + Mosquitto.

You will find more info here about the new gateways http://forum.mysensors.org/topic/2352/guide-setting-up-and-testing-mqtt-client-gateway .

Download of development (and master) branch is here https://github.com/mysensors/Arduino .

@Matt-Pitts When running Openhab as a daemon some typical listings in my event.log are:

2016-02-14 08:05:24 - node2_pulsecounter_in state updated to 30568
2016-02-14 08:05:24 - Kwh_node2 state updated to 30.5680
2016-02-14 08:05:24 - Kwh_diff state updated to 0.8050
2016-02-14 08:05:25 - Temp_node2_freezer state updated to -19.4
2016-02-14 08:05:53 - Temp_dining state updated to 21.9

Your listing:
2016-02-13 20:36:25.823 [DEBUG] [o.o.i.m.i.MyOpenHABServiceImpl] - store(lounge_Temp), state = 23.0
shows that Openhab has received this value and updated the state. My guess is that you run Openhab with debug output enabled. At least I get this logging format but then in openhab.log when I run from a debug shell.

For moquitto you will see all messages if you subscribe to topic # and if you set the -v flag also the output is a bit more verbose, example:
mosquitto_sub -h 192.168.1.107 -t # -v (I need the -h switch because I do not run it from localhost)

A typical output gives topic and payload and looks like:
mygateway1-out/24/1/1/0/0 -10.6
mygateway1-out/24/2/1/0/1 96

Your topic line will show just this the topic mygateway1-out/3/0/1/0/1 and the -d flag shows debug values.

Since you get a log message and also the graph these values of course must be coming in so if this is the only incoming value you have all is OK. If you have more sensors sending which do not show up in the log then most likely there are errors in the mqtt binding for these items.

Just a comment, in your previous post about the openhab.cfg one line for the broker states:

mqtt-eventbus:commandSubscribeTopic=mygateway1-in/commandUpdates/${item}/command

I think this should be changed to
mqtt-eventbus:commandSubscribeTopic=mygateway1-out/commandUpdates/${item}/command

@Matt-Pitts I have been out for the evening so pls excuse for not replying. I will take a look at it tomorrow but in principle every message which match an item in Openhab will be found in the event.log, at least for the installation I have (i assume you run Openhab as a daemon, if being run from a shell command you will see any matching messages in the opehab.log also)
So if not shown in the event.log it has not been received OK. A few things to check are:

• The message structure has changed from the 1.5 version to the development branch sketches. What I listed above is according the new format. In principle 2 new fields are added and V_XXX is changed to the corresponding numerical code. If the message topic and type is different from what is stated in the item definition nothing will be picked up by Openhab.

• Check the messages from the gateway using for example the mosquitto _sub client. This will tell you if the messaged are sent and what format they have.

@Matt-Pitts Just here and nowhere else. It is an arbitrary definition because an auto id will be generated if not stated. Since it seemed to be needed for the broker part I added it even though. The Openhab pages for the MQTT binding will tell you the details.

Update: Should have added that the clientID here is a private affair between Openhab and Mosquitto.

The item bindings will typically look like:

incoming to Openhab: {mqtt="<[mosq1:mygateway1-out/22/1/1/0/17:state:default]"}
outgoing from Openhab {mqtt=">[mosq1:mygateway1-in/22/1/1/0/24:state:*:default]"}

I guess this will answer your question, all designations are confusing. Took me time to sort it out.

@Matt-Pitts It works really well so far. Here are the relevant
parts of my openhab.cfg:

Openhab MQTT to Mosquitto

mqtt:mosq1.url=tcp://localhost:1883
mqtt:mosq1.clientId=MyMQTT-2

Openhab MQTT Eventbus broker

mqtt-eventbus:broker=mosq1
mqtt-eventbus:stateSubscribeTopic=MyMQTT-2/stateUpdates/${item}/state
mqtt-eventbus:commandSubscribeTopic=MyMQTT-2/commandUpdates/${item}/command

The event bus broker part should not be needed but was the one that made it work.

Good luck.

@TommySharp Very nice, hope you realize you have started on a long journey
But try to modify the original sketch, it works really well and will save you a lot of work.

@mbj I tested using the new version for MQTT but unfortunately Openhab will not recognize the empty message sent by gw.request(CHILD_ID, V_VAR1) . The error message is:

2016-02-12 10:41:51.154 [WARN ] [.c.i.events.EventPublisherImpl] - given new state is NULL, couldn't post update for 'node2_pulsecounter_start'

So I was wrong, Openhab will not recognize the message unless the sketch is modified to send something with a payload (which is easily done in many ways, not just the one mentioned above).

If anybody knows a way to bind the gw.request type messages (with null payload) for Openhab MQTT it would be nice to know, please inform.

@TommySharp Actually, if you plan to use any of the new MQTT gateways from the development branch there might be no need to change the Power Meter code.

Reason is that the new format for the MQTT topic now includes the MySensors cmd-type field where requests will have a cmd-type of 2 and sensor value updates a cmd-type of 1 (the new format is MY_MQTT_PUBLISH_TOPIC_PREFIX/FROM-NODE-ID/SENSOR-ID/CMD-TYPE/ACK-FLAG/SUB-TYPE).

It is still needed to define a "start-command-received" item in Openhab but that item can now be attached to the V_VAR1 type message which the power meter sends with the request method.

With the new format things might look something like (I excluded all not needed info like text, formatting etc and changed the string item to a number):

Number node2_pulsecounter_start {mqtt="<[mosquitto:mygateway-out/22/1/2/0/24:state:default]"}

The inbound pulse count from the power meter will look like this using same message structure:
Number node2_pulsecounter_in {mqtt="<[mosquitto:mygateway-out/22/1/1/0/24:state:default]"}

The outbound pulse count from the controller to the power meter then looks like this:
Number node2_pulsecounter_out {mqtt=">[mosquitto:mygateway-in/22/1/1/0/24:state:*:default]"}

The rule will be the same.

The new MQTT gateway from the development branch is a MQTT client and in these examples the publish topic starts with "mygateway-out" and the subscribe topic with "mygateway-in" and the broker is called "mosquitto".

I have not tested this so no guarantees but it ought to work. When I update my power meter sketch I will try it.

Have I confused you enough yet?

@TommySharp When it drops down under -20 to -25 C it is more than 100 KWh. So the pulse counter has a job to do

@TommySharp My sketch is from a prior version of MySensors software and also much modified due to other sensors attached. It will not be of any help to you and right now I have no time to rewrite it to the current code base and libraries, sorry.

But making the change the way I described is quite easy to implement if you take a look at the code and my brief description above. On the Openhab side there are heaps of ways to implement the change depending on what your intended function is. I have added functionality like setting the pulse counter manually in Openhab so also here the logic is quite complex and beyond what is useful as an example.
But basic steps in my implementation are:

• Define a new message of type V_VAR2 (I use it for sending a string, actually does not matter what it is as long as the receiving item matches the type sent. My definition is:

MyMessage pcMsgStart(CHILD_ID,V_VAR2);

• Disable original startup message:

// gw.request(CHILD_ID,V_VAR1);

• Send new startup message based on V_VAR2 (I just send it with a string):

gw.send(pcMsgStart.set("START"));

• Create a receiving item in Openhab, I use just a string Item:

String node2_pulsecounter_start "Start för pulsecounter[%s]" (gEnergy) {mqtt="<[mysensor:MyMQTT/22/1/V_VAR2:state:default]"}

• Create sending item in Openhab. I use this one:

Number node2_pulsecounter_out "Count out [%.0f pulser]" (gEnergy) {mqtt=">[mysensor:MyMQTT/22/1/V_VAR1:state:*:default]"}

• I also have a receiving item to get the actual pulse counter into Openhab once the sensor is running:

Number node2_pulsecounter_in "Count in [%.0f pulser] " (gEnergy) {mqtt="<[mysensor:MyMQTT/22/1/V_VAR1:state:default]"}

Then you just need to make rule for sending a pulse counter back to the sensor. Here is the rule:

rule "Pulsecounter node 2 startvalue"
when
Item node2_pulsecounter_start received update
then
{
postUpdate (node2_pulsecounter_out, pulsecounter)
}
end

So when the sketch sends the start message Openhab senses an update of this V_VAR2 value and returns the requested pulse count ( which is set to 0 at startup or a previously incoming value at a restart or a setpoint value from elsewhere in the logic). But you can always use O to get going without any complications.

I am basically interested in the energy consumption per 24 hours so I reset the counter at midnight. The absolute exact consumption is clearly stated on my energy bill so for follow-up the daily consumption is the most interesting one. Below you can see how I graph the values and I have successfully used these to spot problems. Our house is electrically heated so with a consumption of 15000 - 18000 KWh each year there are good reasons to keep an eye on it.

Hope you can follow the logic because unfortunately it does not make any sense to even try to explain the full set of rules which I use for this.

It is also possible that I today could sniff the original gw.request message from the sketch and fix a reply from Openhab but this was the simplest functional solution I could think of at that time.

@soloam Yes, the state makes the difference of course. Because you had used command for all definitions I assumed that your intention was to also send in a command from outside of Openhab to control the light.
Glad you found a solution.

@gregl I have used this procedure a few times:

• Define for example a V_VAR1 message for the query (or use any other suitable message type depending on purpose),
• Make a MQTT binding for this message i Openhab (for example bind it to a switch, a number or whatever fits the purpose)
• Make a rule in Openhab that reacts on this incoming message ("When Item xxxxx received update then ......)
• Fix whatever logic is needed in this rule so you can send the queried info back to the sensor. If no existing binding is suitable you can of course define a V_VAR2 message (or use other type which fits) for the return message.
• In the "Incomingmessage" function use whatever logic is needed to decode the returned message.

Reason for choosing a custom type of message (like a V_VAR2) for sending the info back is of course that it is easy to sort it out from the stream entering the incoming messages function. If you have no other incoming messages or the logic for the queried info already is in place then you do not have to think about this.

Hope the explanation is understandable, if not please revert.

@soloam Your binding actually is:

Switch node2_sw2 "sw2 send + recieve example" (node2,all) {mqtt=">[mysensor:MyMQTT/21/2/V_LIGHT:command:ON:1]}
Switch node2_sw2 "sw2 send + recieve example" (node2,all) {mqtt=">[mysensor:MyMQTT/21/2/V_LIGHT:command:OFF:0]}
Switch node2_sw2 "sw2 send + recieve example" (node2,all) {mqtt="<[mysensor:MyMQTT/21/2/V_LIGHT:command:MAP(1on0off.map)]"}

Not that it matters for your problem but the first two I think can be replaced with:

Switch node2_sw2 "sw2 send + recieve example" (node2,all) {mqtt=">[mysensor:MyMQTT/21/2/V_LIGHT:command:*:default]}

This is what I think happens: When you toggle the switch in Openhab to ON this is placed on the bus and sent as a MQTT message. The third definition binds exactly the same item to an inbound command so then Openhab reads it executes this command which is put on bus and the is read again by the incoming binding and so on. Effectively you have created a loop by adding the 3rd binding to the first two.

One solution is to use two switches, one for incoming commands and one for outgoing, like this:

Switch node2_sw2-1 "sw2 send example" (node2,all) {mqtt=">[mysensor:MyMQTT/21/2/V_LIGHT:command:*:default]}
Switch node2_sw2-2 "sw2 recieve example" (node2,all) {mqtt="<[mysensor:MyMQTT/21/2/V_LIGHT:command:default]}

Then you use the first one to trigger outbound messages and the second one to read incoming. If you want to see the current state of the lamp (the first switch) in openhab you can use a rule to set that according to changes made by any incoming message.

I do not know if this is the way but I think it will work.

You may find it useful to take a look at the definitions Openhab MQTT bindings: https://github.com/openhab/openhab/wiki/MQTT-Binding.

The format for inbound and outbound messages are different. In your incoming definitions there is a transformation of "ON" or "OFF" and there is a regex filter of "1" or "0" so the question is if these definitions can be used for anything (incoming is "direction, broker, topic, type, transformation, regexfilter"

It is a bit difficult to understand what you mean by "The problem is when I push a notification", from where do you push something, in what format and what shall it be used for? Type for Openhab messages which can be bound to an item is either a state change or a command´,

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.

I have not observed that Openhab can answer any controller-type messages. For any such messages I have had to build my own logic to fix it.

In this case the message is of type 3 (= internal message) with a subtype of 1 (= I_TIME) and Openhab does not have a clue what this is until you define an item and use rules to respond correctly.

In other cases I have found that the easiest route around it is to define an own message using for example a V_VAR type and then pick this one up in Openhab.

Good Luck!

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).

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.

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

@hek Thank's for the info. I have missed any discussions about the change but as I am sure I am not the only one please add some text about the new format as a comment to the sketch whenever convenient. Might save some calls for support

@Yveaux Thank's for a quick reply. The current message (1.5) shows up with type (like V_TEMP) in third position in the received message at the Openhab end. Item def thus is something like MyMQtt/24/1/V_TEMP:state:default.

The received message from new version as sniffed by a MQTT.fx client is MyMQTT/24/1/1/0/V_TEMP which thus means a rewrite of all definitions in Openhab.

I am not sure this is a bug or an intentional change of the MQTT message structure.

The version 1.5 Gateway has the code:

inline MyMessage& build (MyMessage &msg, uint8_t destination, uint8_t sensor, uint8_t command, uint8_t type, bool enableAck) {

while the ESP8266MQTTClientGateway uses:

       snprintf_P(_fmtBuffer, MY_GATEWAY_MAX_SEND_LENGTH, PSTR(MY_MQTT_PUBLISH_TOPIC_PREFIX "/%d/%d/%d/%d/%d"), message.sender, message.sensor, mGetCommand(message), mGetAck(message), message.type);

The disadvantage is of course that when upgrading to the ESP8266MQTTClientGateway a lot of coded definitions in for example Openhab have to be changed (I have no experience of how other controllers will handle this).

@m26872 I did not note the numbers but worst case was 4-6 deg C at -20 to -25 ( ie 18B20 showed -18 and the Micro -24).

I should have replaced the 18B20 to see if it made any difference but it was so cooooold out there. Also I have a feeling that the Sensebender might have been slightly lower than the truth as well but clearly much more in line with other readings available.

Right now the readings are +4.2 for the mailbox and +3.6 for the 18B20 and since they are at different levels this is perfectly fine.

I have not checked the specs for either of the sensors and have also noted that there are numerous articles about calibrating the 18B20 but never bothered dive into the issue. And then also comes the issue if the ones I have are genuine or "Chinese clones".

@sensorchecker You may get a little job to do, the sketch is made for the Sensebender Micro and I have no idea how it will compile for the "slim-battery-node".

@moskovskiy82 You will find the discussion in the threads if searching. The current v1.5 gateway is a (rough) broker with some problems (even though mine has run well for a long time).

The next one is a MQTT client and is based on ESP8266 and is available from the development branch at GitHub. Using this you also need a broker, for example Mosquitto, somewhere in the network.

I have just installed Mosquitto at my Openhab RPi gateway and will start testing the WSP8266 MQTT gateway client one of these days. I have already run it for a few minutes and it worked so far.

@sensorchecker I can of course share the sketch but need to do some more work on it before publishing anything. How do you communicate between MySensors items and Openhab?

Some answers to your questions:

I have not found any way to make Openhab distribute node id's automatically, at least not for the Openhab 1.x versions. I use the current MySensors MQTT gateway together with Openhab and this gateway can issue node id's. But next release of the MySensors software will not support the current MQTT gateway so no reason for trying it. On the other hand, it is easy to set the node id's manually so why not continue doing that?

I am running the gateway on a nano, works fine. For battery powered sensors (I have just one now) I have used the Sensebender Micro which seems to consume very little power if correctly programmed (you can see a little more info here http://forum.mysensors.org/topic/2960/yet-another-mailbox ). For other options see for example https://www.mysensors.org/build/battery or similar advices available on the Internet.

I have a z-wave network connected to same Openhab as used for the MySensors items and it runs on a RPi. So Openhab is the glue between the various networks. I have never tried any ZigBee stuff and currently see no reason to use any because MySensors works great on NRF24 (and presumably great also on RFM69).

The references cited do list quite a few arguments for not using NC and I think those are relevant.

These items are made by enthusiasts for enthusiasts. Companies need to make money and they will not make heaps on something like this. Most of all open source items are small things which will not rock the world and if any manufacturer needs something similar they will earn more money on an own solution.

And the Chinese will copy any interesting solution whether marked NC or not

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 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.

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.

Thanks for the answer. When tracing the error also I found these settings and have already tried this change but without any success. I may have forgotten to save the change or something else so will try it again.

I know that mosquitto as well as the ESP8266 is working OK because I tested another sketch (https://gist.github.com/igrr/7f7e7973366fc01d6393) also based on the pubsub client and this works perfectly.

Btw, in case of interest for anyone, when compiling for a DHCP IP-address there are compiling errors for missing gateway and subnet addresses. Not any problem but assume it should be corrected to some future release.

Will post any progress, have reinstalled Raspbian based on Jessie- version because this was on the schedule anyhow.

A nice project.

I had a similar problem with a freezer located in the garage.

As I already had other temperature sensors and an energy meter running there (based on MySensors stuff) I just added one of these waterproof DS18B to the setup, drilled a hole through the fridge wall and stuck it in.

I use OpenHab and can see the temperature on any browser or at the cell phone client. OpenHab also emails me when temperature raises above a certain temperature.

Not as sophisticated as your solution but it works

The ESP8266 gateway does not connect to the Mosquitto server (on a RPi). The broker is up and running, all other type of clients can connect and pub/sub messages and the ESP8266 is up and running on the network. Here are a few lines from the log:

AtxGùHøÙ¬D:läÿ0;255;3;0;9;Starting gateway (RNNGE-, 2.0.0-beta)
0;255;3;0;9;Radio init successful.
scandone
state: 0 -> 2 (b0)
.state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 4
pm open phy_2,type:2 0 0
cnt

connected with XXXXX, channel 6
ip:192.168.1.22,mask:255.255.255.0,gw:192.168.1.1
.IP: 192.168.1.22
0;255;3;0;9;Init complete, id=0, parent=0, distance=0
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;read and forward: 54-22-8 s=1,c=1,t=17,pt=5,l=4,sg=0
0;255;3;0;9;send: 54-0-52-8 s=1,c=1,t=17,pt=5,l=4,sg=0,st=fail:2168321
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;read: 22-22-0 s=4,c=1,t=0,pt=7,l=5,sg=0:-18.5
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;read: 56-22-0 s=1,c=1,t=0,pt=7,l=5,sg=0:0.7
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;read: 22-22-0 s=1,c=1,t=17,pt=5,l=4,sg=0:4929
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;Attempting MQTT connection...

Adding some debugging to the Mosquitto end shows this:

Jan 24 19:54:42 RPi5 mosquitto[3016]: Invalid protocol "MQTT" in CONNECT from 192.168.1.22.
Jan 24 19:54:42 RPi5 mosquitto[3016]: Socket read error on client (null), disconnecting.
Jan 24 19:54:58 RPi5 mosquitto[3016]: New connection from 192.168.1.22.
Jan 24 19:54:58 RPi5 mosquitto[3016]: Invalid protocol "MQTT" in CONNECT from 192.168.1.22.
Jan 24 19:54:58 RPi5 mosquitto[3016]: Socket read error on client (null), disconnecting.
Jan 24 19:55:13 RPi5 mosquitto[3016]: New connection from 192.168.1.22.
Jan 24 19:55:13 RPi5 mosquitto[3016]: Invalid protocol "MQTT" in CONNECT from 192.168.1.22.
Jan 24 19:55:13 RPi5 mosquitto[3016]: Socket read error on client (null), disconnecting.
Jan 24 19:55:28 RPi5 mosquitto[3016]: New connection from 192.168.1.22.
Jan 24 19:55:28 RPi5 mosquitto[3016]: Invalid protocol "MQTT" in CONNECT from 192.168.1.22.
Jan 24 19:55:28 RPi5 mosquitto[3016]: Socket read error on client (null), disconnecting.
Jan 24 19:55:43 RPi5 mosquitto[3016]: New connection from 192.168.1.22.
Jan 24 19:55:43 RPi5 mosquitto[3016]: Invalid protocol "MQTT" in CONNECT from 192.168.1.22.
Jan 24 19:55:43 RPi5 mosquitto[3016]: Socket read error on client (null), disconnecting.
Jan 24 19:55:58 RPi5 mosquitto[3016]: New connection from 192.168.1.22.
Jan 24 19:55:58 RPi5 mosquitto[3016]: Invalid protocol "MQTT" in CONNECT from 192.168.1.22.
Jan 24 19:55:58 RPi5 mosquitto[3016]: Socket read error on client (null), disconnecting.
Jan 24 19:56:13 RPi5 mosquitto[3016]: New connection from 192.168.1.22.
Jan 24 19:56:13 RPi5 mosquitto[3016]: Invalid protocol "MQTT" in CONNECT from 192.168.1.22.
Jan 24 19:56:13 RPi5 mosquitto[3016]: Socket read error on client (null), disconnecting.

The code for the gateway (including all libraries) was downloaded yesterday from the development branch and the broker is the latest version from the Mosquitto wheezy repository.
Seems to be something basic in the connect procedure.
Any ideas Anyone??

Hi,
When testing the ESP8266MQTTClient (downloaded latest version of the library today) and compiled with the NodeMCU 1.0 ...... option I get an odd result. The message at startup is (please disregard the "Radio init fail" - the radio was not yet connected. I just wanted to check the WiFi

2dO,4`lLMØl 8ðÿ0;0;3;0;9;Starting gateway (RNNGE-, 1.6.0-beta)
0;0;3;0;9;Radio init failed. Check wiring.
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 2
pm open phy_2,type:2 0 0
cnt

connected with XXXyyy, channel 1
dhcp client start...
ip:192.168.1.167,mask:255.255.255.0,gw:192.168.1.1

I can see from the router that the connection to 192.168.1.167 is successful but the oddity is that I have set the gateway to use a static address and also connect to a SSID which is not XXXyyy. The defines are:

// Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP)
#define MY_IP_ADDRESS 192,168,1,22
// If using static ip you need to define Gateway and Subnet address as well
#define MY_IP_GATEWAY_ADDRESS 192,168,1,1
#define MY_IP_SUBNET_ADDRESS 255,255,255,0

So the ESP8266 uses dhcp when it should have a static address and connects to a SSID which is not given but may have been previously used at earlier tests.

I have looked at the code and tried a few changes to defines but none resulted in the override of dhcp.
Anyone have a clue?

@petoulachi D3 can be used for interrupt, just tested it and it works.

@insomnia I can not see any defined interrupt or the interrupt related function in your code. Starting with the Arduino docs is often helpful why I suggest taking a look at https://www.arduino.cc/en/Reference/AttachInterrupt. For only one switch a hardware interrupt will work fine.

If you need to monitor a few more switches and you use an Arduino with 328P processor there are only 2 hardware interrupts available. Then the pin change interrupts may help but the task is getting more complicated, see for example http://playground.arduino.cc/Main/PinChangeInterrupt but there are libraries like https://github.com/GreyGnome/EnableInterrupt (which I so far not have tested).

Then there are ways of dealing with heaps of interrupts as well but that is far beyond my knowledge.

@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

@hek Is it needed for the radio to work or can I just cut it (seems odd to attach the radio to D2 if it is not really needed for anything).

@hek said:

@gbfromhb

D3 is available on the side-pins. D2 is routed to the radio but can be used with some hacking.

I need 2 interrupts and would prefer using the external interrupts even though it might work with pin change interrupts. When looking through the forum I saw this answer from @hek but have not found any further reference to how this should be done in order not to disturb any radio functions. Anyone knows?

I use a cheap Chinese 5100 module together with the MQTT gateway and it is warm but have not measured any actual temperature. Works 24 hours a day (now for a couple of months). Most problems have been due to the MQTT code implementation itself . But for most "simple" sensors it runs OK with Openhab.

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

Seems to be same issue as I posted in "RTC sensor and Openhab". I guessed the problem was on the Openhab side but looking at the output from the various logs it seems that the MQTT causes this and this post points to the same cause.

@gadu Glad to be of any help, your turn next

Unfortunately I am a beginner with all this but I have been successful getting messages over to Openhab via the MQTT binding.

I can guess that the "sendBatteryLevel" example from the API pages is tailored for a Vera controller or similar but is not at all understood by Openhab. I have come across something similar when other sensors send commands directed to the controller itself.

So my assumption was that if you should send something across that Openhab understands you could test creating a message like your example msgvolt and then send the info with something like gw.send(msgvolt.set(batteryV)) or gw.send(msgvolt.set(batteryV,1)) and pick this up with an item in Openhab.

The messages type V_VAR1 and onwards can be used for custom values so I think you can use one of these to send the battery level percentage. Only way to find out is to experiment