Just to let you know that I am very happy with this binding.
One thing for others to be aware of:
If you use PaperUI for configuring etc, make sure you leave Simple Mode off if you expect to use Groups later on. Simple mode adds the items (including the VAR1-5 :-() automatically but they are not 'managed'. This means you will get 404 and 405 errors on trying to edit them later on.
My solution was to let the binding autodiscover and add the Things. Then add 1 Item manually so that the \\192.168.0.123\openHAB-share\openhab2-userdata\jsondb\org.eclipse.smarthome.core.items.Item.json
file gets created and filled with an example to clone. I then added the various sensors using Name of pattern <binding name><sensorname><nodeid>_<dataname>, e.g. "mysensors_light_level_node4_last_update": { "class": "org.eclipse.smarthome.core.items.ManagedItemProvider$PersistedItem", "value": { "groupNames": [ "gLastUpdated" ], "itemType": "DateTime", "tags": [], "label": "Last", "category": "calendar" } },

You must stop Openhab before editing the file (else you will lose your edits) but once it starts up again you will see the Items listed in PaperUI (and VSCode if you use that). You can then add the Channel/Item links for each Thing.

@TimO said in openHAB 2.2 binding:

@LastSamurai

The channel is not correct:

channel="mysensors:multimeter:gwSerial:voltageSensorWZ:volt"

It's confusing, but that's the way OpenHAB2 handles channels. :confused:

Is the pattern:
<binding name>:<mysensors type>:<gateway id>:<thing name>:<data name> ?

@sveness I think he is aware, there is a GitHub issue open on the topic.

In PaperUI, goto Configuration/Things/MySensors Ethernet Gateway. Set Disable Network Sanity Check to On (the label is named backwards). This sends a status check at your defined interval. This will reconnect your gw if it fails x times. (See other config params on that page)

In PaperUI, goto Configuration/Things/MySensors Ethernet Gateway. Set Disable Network Sanity Check to On (the label is named backwards). This sends a status check at your defined interval. This will reconnect your gw if it fails x times. (See other config params on that page)

I submitted an issue on the BH1750 library, which was fixed. So OneTime modes now work as expected.
https://github.com/claws/BH1750/issues/17

US4.90 for 10 boards (100x50) on special, US4.85 shipping to Canada.

The default surface finish at Elecrow is HASL. ENIG is goldie colour but more expensive. There are a few others as well.
Good explanation of differences: http://www.epectec.com/articles/pcb-surface-finish-advantages-and-disadvantages.html
OSH might be using OSP / Entek coating.

IMHO it is an appearance thing for us hobbyists. As long as it is not bare copper it should be ok.

Very pleased with my Elecrow order as well. This is the first pcb I designed since the 1980's when you taped up the art work by hand :-)

@DavidZH Any place where I can see your proposed changes? I am using @freynder 's approach but would like something more portable for future use.

Not sure if you ever solved the BH1750 problem. I had same issue, the BH1750 library does not correctly handle the case where One Time is configured as mode. The sensor literally powers down after the command is executed. You would need to wake it up again by issuing a Power On command (0x1) according to data sheet.
I switched to using BH1750_CONTINUOUSxxxx but then I am not looking to save the few microA. My attempts to fix the driver library haven't succeeded yet :-( I would prefer it worked properly with BH1750_ONE_TIMExxxx.

Seriously major work on this release, just in time for me to start up my sensor project again. Thank you!

The regulator has 3 terminals, on one side, 2 on the other. Usually near 2 'large' capacitors

I would check the part number on the regulator. Just because it is sold as 3.3V mini doesn't mean that it is :-(
Feeding >3.3VDC to the radio potentially made it give up its magic smoke.

Hi,
See the above mentioned topic, there is a solution to using esp8266/Arduino 2.1 library.

The credit should really go to @sle118 but I will create a pull request later today.

And now that we know exactly what to look for, I found this: https://github.com/esp8266/Arduino/issues/1695 where they library fix is being implemented as well as a description of the problem.

Being Dutch I am very stubborn, a bit like a leach with lockjaw when it comes to defects.
@hek
Some more searching today turned up issues with esp8266/Arduino and the yield() function. That led to me looking through the MySensors site again and it turns out that a month ago in this set of comments that http://www.mysensors.org/build/esp8266_gateway user sl118 solved the problem by commenting out a line in MyGatewayTransportEthernet.cpp. I should have twigged on that earlier as someone elsewhere commented the using UDP solved the problem as well.

The setnodelay(true) enables the Nagle algorithm inside the tcp stack, this combines small packets into a larger one. So perhaps a bit of a performance hit on a busy network but at least I can use esp8266/Arduino 2.1 now and avoid using Arduino IDE for gw, and use VS2015CE for all my development again.

There is a problem with this configuration and ESP8266/Arduino 2.1 library.
See http://forum.mysensors.org/topic/3524/solved-wifi-gateway-problem-esp8266/2 for more details.

Have you tried the esp8266 as a sensor node or just with some of the esp8266 examples? Just trying to see what we can eliminate from the search for a solution.

I ran out of time last night.....
There are at least 4 Issues open at ESP8266/Arduino on this topic. Most of the exception dumps seem to fail inside a timer interrupt????
I reverted the EEPROM library to 2.0.0, no change.

Adding a 1 second delay (wait(1000)) just before the EEPROM read (after leds_init) avoids the exception but results in a wdt event and restart.

There are 80 files changed in cores/esp8266 since 2.0.0. I might do some diffs to see if there is anything that hints at being relevant. No telling what the cause is so binary search might be the only way without a hardware debug facility.

Bottom line, for me I might have to live with using 2.0.0 until the esp8266 Arduino lib team figure this one out. :-(

I wouldn't call downgrading a solution, but it is a useful workaround :-)

Since this isn't actually solved and because I want to not downgrade the sdk I did some tracing.
I added printf's to MySensorCore.cpp to see how far we get before the exception occurs. The ledsInit() at line 113 returns , but we crash somewhere during the hwReadConfigBlock() call to get the isMetric parameter. If I comment that out execution continues but fails after calling presentation().
This seems to implicate the EEPROM library calls from MyHwESP8266.cpp and indeed when I add printf's there (oh how I hate debugging this way!!!), it fails on the call to EEPROM.init(length).