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

gerritv created this issue in claws/BH1750

closed Reading light level fails if using the ONETIME modes #17

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

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

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

@gerritv I will answer the question myself.

The directory layout of MySensors is a bit unusual, requires the following layout in platformio.ini

[platformio]
lib_dir = ../lib

[env:nanoatmega328]
platform = atmelavr
framework = arduino
board = nanoatmega328
build_flags = -I../lib/MySensors
lib_ignore = MySensors

The directory layout I use is:
Top level, a directory called lib with the contents of MySensors development branch. Inside this top level directory you have your various projects relating to this Solution:
A directory for your sensor node sketch, e.g, LivingRoomNode which contains the Platformio directory and the above info in its ini file
A directory for your gateway, with the same library parameters

The result is a solution with multiple source projects pointing at the same MySensors library.

Platformio is a great way to develop ESP8266/Arduino etc code. Also Platformio works very well with Visual Studio 2015 CE (this is what I build my MySensors nodes and gateways with).

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.

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.

luc-github created this issue in esp8266/Arduino

closed on 2.1.0 server.setNoDelay(true); generate exception(2) at start #1695

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.

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

gerritv created this issue in claws/BH1750

closed Reading light level fails if using the ONETIME modes #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.