OpenHAB

Hi @adds666 I did in between the switch from 2.5.12 to 3.4.4 a change from pure textual configuration in 2.5.12 to a UI configuration in 3.4.4. This requires some homework. Can't remember beside the exchanged mysensors binding files anything else to upgrade to 4.0.4 from 3.4.4 and finally to current 4.1.1. Keep in mind, I use a OpenHAB manual installation on a non-Debian Linux system, not openHABian. This may have an influence, but I don't expect any hiccups. kerberos

Hi @CyborgAndy many thanks for providing the binding update for MySensors 4.0.4! I upgrade my OpenHAB 3.4.4 a few minutes ago to 4.0.4 successfully with your binding update. I use a USB connected serial-gateway. The OpenHAB manual installation upgrade works perfect. I need to do afterwards the following steps in the Karaf console, to get the gateway online again, after the update: feature:install openhab-transport-serial feature:install openhab-core-io-transport-mqtt feature:install openhab-core-io-transport-serial-javacomm Many thanks again! kerberos

@ben999 Check out Serial Protocol I have four Arduinos. Each has a different MY_NODE_IDs (I use 130, 131, 132, 133). Each has four sensors: moisture, humidity, temperature, and voltage each of which has a CHILD_ID: CHILD_ID_MOISTURE is 0 , CHILD_ID_HUMIDITY is 1, CHILD_ID_TEMPERATURE is 2, CHILD_ID_VOLTAGE is 3. When an Arduino makes a measurement, it sends that measurement to a unique MQTT topic. In the case of the Arduino with MY_NODE_ID of 130 that is sending the moisture measurement, that MQTT topic is mysensors_out/130/0/1/0/35 and the message is [something like] 760 (35 is the value type) Similarly, when a controller sends a command to a device (Arduino), the topic is unique. If you have two actuators with the same MY_NODE_ID and CHILD_ID (MQTT topic) there would be confusion as to what you want each actuator to do. Likewise, if two sensors had the same MQTT topic, how would the controller know how to handle the data.

@syntacrsc good job man

@chrishiscox said in OH3 Serial Gateway Problem: I tried and tried with my serial gateway, and never got it to function porperly. The serial port was working I could see it and data, but OH3 just refused to recognise the data. After a week, I decided to abandon the serial and flashed a esp8266 attached the nRF to it and bobs my uncle as we say. It goes via MQTT, so takes a little more settting up but works fine. If you want more info I will dig out the pages I used to make it work. Hmmm, the pi OH is running on already has an active MQTT broker. So you got me thinking: Wouldn't it be possible to use the MQTT gateway instead of the serial gateway? It should be able to translate radio messages (Hope RF69 in my case) to mqtt messages which are already recognized by OH. I'll have to find a spare pi and try it.

Replying myself after more reading and testing. *MQTT vs ETH probably is equivalent in my system, if the choice if given I think MQTT is preferred. *NRF24 or RFM69, maybe both as I already have a bunch of NRF24 radios home and can start build directly. *PC based MQTT could be an idea, but probably its as easy to work through an Arduino-example using the serial monitor in an Arduino-environment. My way forward will be: Remove the RPi-GPIO-gateway (I built a basic node and tested it, but could not communicate with the GW) and replace it with ESP8266-based WIFI/MQTT/Radio-gateway (one with NRF24 and eventually one with RFM69). I believe that will be an easier way into mySensors-world also limiting the amount of required Linux-related knowledge. It will be easier to debug the system from Arduino IDE-serial console. Ie start and confirm OH3 to MySensors-MQTT-gateway, then proceeding with sensor to gateway communication etc.

@ncollins Great! Seem the problem is the delay. With 1 ms or 100 ms I have double message, but with 200 ms I only one message. Thanks a lot.

@TimO No Sweat, found it :D - it was because the node was powered on before the gateway and presentation didn't go well...

Hi, sorry for the delay in replying, I got caught up on other things... I (think?) I'm using the MQTT2 binding in OH. In the PaperUI --> Add-ons --> Bindings, the only one showing as installed is "MQTT Binding (binding-mqtt - 2.5.4)". I'm running separate Docker containers for MySensors Gateway, Mosquitto and OpenHab. Since people seem to be using text files for configuration successfully, I'm going that route too (version control, scripted/automated builds, etc). These are the configuration files I've got so far (sanitised as appropriate): $ cat openhab/conf/things/mysensors.things Bridge mqtt:broker:Mosquitto "Mosquitto" [ host="192.168.10.114", port="1883", secure=false, clientID="OpenHAB", username="mqtt_user", password="mqtt_password" ] { Thing topic nodePrototype1 "Prototype Node" @ "Portable" { Channels: Type number : temp "Temperature" [ stateTopic="mysensors-out/1/0/1/0/0", unit="°C" ] } } $ cat openhab/conf/items/mysensors.items Number Prototype_Temp "Temperature" <temperature> {channel="mqtt:topic:Mosquitto:nodePrototype1:temp"} OH is successfully displaying the temperature in PaperUI, but I haven't tried to do anything with it yet...

@itbeyond I'm glad to hear you finally found the cause! The current jar is published via the download link on the wiki page: https://github.com/tobof/openhab2-addons/wiki/Installation And via eclipse marketplace. There is currently no active development, I only try to ensure the binding is running fine with the most current release of Openhab2.

Thank you @hard-shovel! It works. It doesn't store the value between reboots but I guess that's a different topic which I will look into. Cheers

That's great news! Now back to the fun part! :) I prefer to have a repeatable, definable failure mode, and then fix that, rather than an unknown success, but that's just me. :D

I came across this post while looking for some information, and I realize this post is quite old, but I wanted to resurrect it for a couple reasons: It looks like OP made a few posts and then never came back since 2018, so maybe they gave up (I know I have been there, more than once). I have come across a lot of posts like this while looking things up and I always find it quite sad that they never so much as received a single reply. There are almost 600 views, so clearly I am not the only one looking for this information. Therefore, @FredRoot, if you read this, just curious if you ever got it sorted. And for anyone else reading, OpenHAB has changed a bit in the meantime, but I am pretty familiar with it, and so I could post a working example should anyone need it. Although this is really more of an OpenHAB question, and therefore perhaps more appropriate for their forums.

@waspie said in Is MySensors Binding needed in addition to MQTT Binding (in OpenHAB 2.5.5)? (aka request() node state via MQTT): I had initial problems with the 2.4 binding and went MQTT only. Pretty much my exact experience as well. I've been really happy with the plain vanilla Ethernet / MQTT gateway (without MySensofs binding) so far this time around. But I'm easing into it slowly and lightly, bit by bit this time. But so far, so good! :) I probably have dug into the MQTT and MySensors protocols, as well as pure textual configuration of OpenHAB well enough to probably figure out the issue I originally posted about. But then I realized I probably don't need to get state from the controller... This node will be a 3 relay node to control my HVAC (fan, compressor, heat) and so it really doesn't need state on startup. They can just start up always off, and then when temperature, humidity or other settings / rules demand it, controller will just tell the relays to turn on. I think I was at the end of like a 14 hour bender of reading and working on stuff when I made that post. Some times, you should just go to bed, instead. :D :D :D One thing I guess I am still curious on is: what functionality exactly does the OpenHAB binding provide, other than auto-discovery and (probably much) easier node management and creation? Because I struggled a bit at first, but now that I am over that hump, I am actually really glad all my config is in plain text files instead of some hidden automagical database deep inside the bowels of Java and OpenHAB. :D

I have tried this on my test system and i get the same results as you using the VAR1 -- VAR5 with the cover (RollerShutter) thing. However if you add CustomSensor thing to your node then using the VAR1-VAR5 work as expected with the mapping. With numbers to and from the node. things cover Mock_Cover [nodeId=254, childId=6 ] text Mock_info [nodeId=254, childId=7 ] Items Rollershutter Mock_Cover_State "Mock Cover State [%s]" <rollershutter> (test254) { channel = "mysensors:cover:gatewayWIFI3:Mock_Cover:cover" } Number Mock_Info_Var1 "Mock Info Variable 1 (number) [%s]" (test254) { channel = "mysensors:text:gatewayWIFI3:Mock_Info:var1" } String Mock_Info_Var1s "Mock Info Variable 1 (string) [%s]" (test254) { channel = "mysensors:text:gatewayWIFI3:Mock_Info:var1" } Number Mock_Info_Var1m "Mock Info Variable 1 (number) [MAP(curtains.map):%s]" (test254) { channel = "mysensors:text:gatewayWIFI3:Mock_Info:var1" } String Mock_Info_Var1sm "Mock Info Variable 1 (string map) [%s]" (test254) { channel="mysensors:text:gatewayWIFI3:Mock_Info:var1" [profile="transform:MAP", function="curtains.map"] } Number Mock_Info_Var2 "Mock Info Variable 2 (number) [%s]" (test254) { channel = "mysensors:text:gatewayWIFI3:Mock_Info:var2" } Number Mock_Info_Var3 "Mock Info Variable 3 (number) [%s]" (test254) { channel = "mysensors:text:gatewayWIFI3:Mock_Info:var3" } Number Mock_Info_Var4 "Mock Info Variable 4 (number) [%s]" (test254) { channel = "mysensors:text:gatewayWIFI3:Mock_Info:var4" } Number Mock_Info_Var5 "Mock Info Variable 5 (number) [%s]" (test254) { channel = "mysensors:text:gatewayWIFI3:Mock_Info:var5" } Node #define CHILD_ID_COVER 6 #define CHILD_ID_CUSTOM 7 present(CHILD_ID_COVER, S_COVER, "Roller Shutters"); present(CHILD_ID_CUSTOM, S_CUSTOM, "Reasons"); Or you if you want to send strings you could use String Mock_Info_Text "Mock Info text sting [%s] " (test254) { channel = "mysensors:text:gatewayWIFI3:Mock_Info:text" }

OK got it !!! It was a combination of more failures - with the main one not having read the name of the status message carefully enough : ItemStateChanged(!!!)Event. So as long as battery level is the same ...

Updated to OpenHAB 2.5 with step-by-step instructions switched to Zulu Java