Posts made by gerritv

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

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

@gerritv Sorry, just re-read your msg and you already have the .ino in correct place.
Are you certain there is no .ino outside the src directory? Are you using the development version of the libraries as well as the example from it?
I recently changed my MySensors lib directory to be direct from Git development branch so the platformio lines are a bit different now (but same idea)

[platformio]
lib_dir = ../MySensorsLib/libraries

[env:nodemcuv2]
platform = espressif
framework = arduino
board = nodemcuv2
build_flags = -I../MySensorsLib/libraries/MySensors
lib_ignore = MySensors
targets = upload

Example output from my recent build:

1>------ Build started: Project: GW-ESP8266, Configuration: Debug Win32 ------
1>  [04/07/16 11:47:31] Processing nodemcuv2 (framework: arduino, build_flags: -I../MySensorsLib/libraries/MySensors, lib_ignore: MySensors, platform: espressif, board: nodemcuv2, targets: upload)
1>
1>  xtensa-lx106-elf-g++ -o .pioenvs\nodemcuv2\src\tmp_ino_to.o -c -fno-rtti -fno-exceptions -std=c++11 -Os -mlongcalls -mtext-section-literals -falign-functions=4 -ffunction-sections -fdata-sections -MMD -DF_CPU=80000000L -D__ets__ -DICACHE_FLASH -DESP8266 -DARDUINO_ARCH_ESP8266 -DARDUINO_ESP8266_ESP12 -DARDUINO=20100 -DPLATFORMIO=020805 -U__STRICT_ANSI__ -IC:\Users\gerrit\.platformio\packages\framework-arduinoespressif\tools\sdk\include "-IC:\Users\gerrit\Documents\My Projects\SensorNet\MySensorsLib\libraries\MySensors" -I.pioenvs\nodemcuv2\FrameworkArduino -I.pioenvs\nodemcuv2\FrameworkArduinoVariant -I.pioenvs\nodemcuv2\EEPROM -I.pioenvs\nodemcuv2\SPI -I.pioenvs\nodemcuv2\ESP8266WiFi src\tmp_ino_to.cpp
1>  xtensa-lx106-elf-g++ -o .pioenvs\nodemcuv2\firmware.elf -Os -nostdlib -Wl,--no-check-sections -u call_user_start -Wl,-static -Wl,--gc-sections -Wl,-wrap,system_restart_local -Wl,-wrap,register_chipv6_phy -Wl,-T"esp8266.flash.4m1m.ld" .pioenvs\nodemcuv2\src\tmp_ino_to.o -LC:\Users\gerrit\.platformio\packages\framework-arduinoespressif\tools\sdk\lib -LC:\Users\gerrit\.platformio\packages\ldscripts -L.pioenvs\nodemcuv2 -Wl,--start-group .pioenvs\nodemcuv2\libFrameworkArduinoVariant.a .pioenvs\nodemcuv2\libFrameworkArduino.a -lmesh -lwpa2 -lsmartconfig -lpp -lmain -lwpa -llwip -lnet80211 -lwps -lcrypto -lphy -lhal -laxtls -lgcc -lm .pioenvs\nodemcuv2\libEEPROM.a .pioenvs\nodemcuv2\libSPI.a .pioenvs\nodemcuv2\libESP8266WiFi.a -Wl,--end-group
1>  "C:\Users\gerrit\.platformio\packages\tool-esptool\esptool" -eo "C:\Users\gerrit\.platformio\packages\framework-arduinoespressif\bootloaders\eboot\eboot.elf" -bo .pioenvs\nodemcuv2\firmware.bin -bm dio -bf 40 -bz 4M -bs .text -bp 4096 -ec -eo .pioenvs\nodemcuv2\firmware.elf -bs .irom0.text -bs .text -bs .data -bs .rodata -bc -ec
1>  <lambda>(["upload"], [".pioenvs\nodemcuv2\firmware.bin"])
1>  Auto-detected UPLOAD_PORT/DISK: COM6
1>  "C:\Users\gerrit\.platformio\packages\tool-esptool\esptool" -vv -cd nodemcu -cb 115200 -cp COM6 -cf .pioenvs\nodemcuv2\firmware.bin
1>  esptool v0.4.8 - (c) 2014 Ch. Klippel <ck@atelier-klippel.de>
1>  setting board to nodemcu
1>  setting baudrate from 115200 to 115200
1>  setting port from COM1 to COM6```

@Iyad-Nahas your .ino file must be in the src directory. I was compiling my ESP8266 gw yesterday with no issues.
I didn't need any customization of platformio. I am using 2.8.5

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

Is anyone successfully using Platformio with development branch?

I am using platformio to do my Arduino development. Works fine if I stick to the Master branch of MySensors (library #548). But if I try to use the Development branch (manually installing it as a library for Platformio) then I get a lot of compile problems that frankly make no sense. E.g. compiling the MQTT demo (GatewayW5100MQTTClient) I get errors in MyGatewayTransportEthernet that EthernetServer and EthernetClient are not a type, aka they were not found in an include somewhere.
http://platformio.org for those wondering.