OpenHAB/MQTT Tips & Hints

[kolaf]

@Yveaux good, I agree, and I am glad to hear it.

How would you solve a toggle switch? The sensor does not know whether the light is on or off since it may be toggled through the controller separately. This means that in my head it will simply send "on" every time and it is up to the item/map to figure out whether it should be turned on or off depending on its current state. I guess this may be required as a rule. Or does your server support sending items dated back to the sensor so that it knows whether the light is off or on currently? In that case it can make the decision itself and send the correct on or off command. Maybe I should ask this question in the openhab group...

[tboha]

@kolaf : I´m not very experienced in Java, so the code reflects my missing knowledge and is much longer than it should be.

The purpose of "Split Message" is to split multilpe messages into single messages and afterward split this single messages into useful informations to set the OpenHAB items accordingly.

First part: common declarations

import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*

var String[] buffer
var String[] linebuffer
var int SensorID
var int transmissions_old = 0
var int transmissions_new = 0  
var int transmissions_missed = 0 
var int RadioID

Second part: Splitting multiple Messages

rule SplitMessage
when 
	Item Arduino changed
 then
 /* Split messages separated with NEWLINE */
linebuffer=  Arduino.state.toString.split("\n")

Third part: Splitting messages according to the serial protocol
buffer(0) = NODE_ID
buffer(1) = CHILD_ID
buffer(2) = MESSAGE_TYPE
buffer(3) = SUB_TYPE
buffer(4) = Message

 for (String element : linebuffer) {
	buffer = element.split(";")
	RadioID = new Integer(buffer.get(0))
	
	switch (RadioID) {
	case 7: {
			SensorID = new Integer(buffer.get(1))
			switch (SensorID) {
				case 0 : postUpdate (MySensorsT0, buffer.get(4))
				case 1 : postUpdate (MySensorsT1, buffer.get(4))
				case 2 : postUpdate (MySensorsT2, buffer.get(4))
				case 3 : postUpdate (MySensorsT3, buffer.get(4))
				} /*switch (SensorID) */
				
			}  /* case 7 */
	case 6: {													 /* ExperimentalNode 6 - soll mal NODE 1 werden */
			if (buffer.get(1)== "10") {							 /* child 10 ist der Homematic Anschluss */
				postUpdate (HMSerialOut, buffer.get(4))	
			} /* if */
	} /* case 6 */
	case 9: {                                                      /* eigentlich war das mal NODE 6 */
			if (buffer.get(1) == "2") {                            /* Child 2 ist der Schrittmacher      */
				transmissions_new = new Integer(buffer.get(4))
				logInfo ("TRANS","Transmissions new " + transmissions_new.toString() )
				logInfo ("TRANS","Transmissions old " + transmissions_old.toString() )
				if (transmissions_old == 0) {transmissions_old = transmissions_new -1 } /* beim ersten mal passiert nichts */
				transmissions_missed = transmissions_missed + (transmissions_new - transmissions_old - 1)
				transmissions_old = transmissions_new 
				postUpdate (Missed_Transmissions, transmissions_missed.intValue.toString)
				postUpdate (Transmission_Count, transmissions_new.toString())
				}
			} /* case 9 */
	case 5: {
				if (buffer.get(1) == "0") { 						/* Child 0 ist die Luftfeuchte */
					postUpdate (MySensorsMobHum, buffer.get(4))
					}
				if (buffer.get(1) == "1") { 						/* Child 1 ist die Temperatur */
					postUpdate (MySensorsMobTemp, buffer.get(4))
					}
							
			} /*case 5: */
	default:	{
			postUpdate (MySensorsNode, buffer.get(0))
			postUpdate (MySensorsChild, buffer.get(1))
			postUpdate (MySensorsMtype, buffer.get(2))
			postUpdate (MySensorsStype, buffer.get(3))
			postUpdate (MySensorsMessage, buffer.get(4)) 
			}
			
	  }   /*switch(RadioID) */ 		   	
	} /*for (String element) */
	
end

So the drawback of the serial binding becomes obvious - every action has to be coded separately. On the other hand it offers enormous controlling possibilities (eg scene configurations),

Fourth part: some actions triggerd from OpenHAB GUI/Webinterface:

rule ArdSwon
when 
	Item ArduinoSwitch changed from OFF to ON
then
	sendCommand(Arduino, "4;2;1;0;2;1\n")
end

rule ArdSwoff
when 
	Item ArduinoSwitch changed from ON to OFF
then
	sendCommand(Arduino, "4;2;1;0;2;0\n")
end

rule HmArdon
when
 Item ArduinoHMSw1	changed from ON to OFF
then
	sendCommand(Arduino, "1;10;1;0;24;HD01004000000\n")
end

rule HmArdoff
when
 Item ArduinoHMSw1	changed from OFF to ON
then
	sendCommand(Arduino, "1;10;1;0;24;HD01004010000\n")
end

To send commands to the MySensors Network you have to use the same "Arduino"Item. In my oppinion another drawback. A separate way out would be nicer. Despite of my oppinion there is no interference between input and output - so i can live with this.

The above example illustrates controlling a LED connected to an Arduino-UNO with the original Relais-Sketch, the second part controls some of my Homematic devices via another MySensors node (connected to Homematic via USB) .

So at last I got a 2.4Ghz network to communicate with my Homematic and an ethernet connection via OpenHAB. In combination with direct interaction between certain MySensor nodes this results in a very redundant and stress-resistant home controlling network.

[Yveaux]

@kolaf said:

Or does your server support sending items dated back to the sensor so that it knows whether the light is off or on currently?

To make sure I understand you right, are both the switch & light located at the same node or do you have a sensor node (switch) and actuator node (light) ?

[kolaf]

@Yveaux said:

@kolaf said:

Or does your server support sending items dated back to the sensor so that it knows whether the light is off or on currently?

To make sure I understand you right, are both the switch & light located at the same node or do you have a sensor node (switch) and actuator node (light) ?

The light is entirely separate from the switch. In my specific case it will typically be a Z-wave relay controlling the light, so I will have to map the toggle switch to the light relay in openhab. This is why I assume I have to use a rule to achieve this.

[Yveaux]

@kolaf Here's my code to use one or two switches to dimm. I hope it gives you some inspiration to connect your zwave switch.

MQTT topics (exposed by the MQTT perl script. Node 120 = switch sensor, node 119 = dimmable light):

/mySensors/120/0/V_LIGHT           switch, reporting 1 when pressed, 0 when released
/mySensors/120/1/V_LIGHT           switch, reporting 1 when pressed, 0 when released
/mySensors/120/2/V_LIGHT           switch, reporting 1 when pressed, 0 when released
/mySensors/119/0/V_DIMMER          dimmable light, accepting integer value between 0 and 100

Items:

Switch Switch_Up               {mqtt="<[server:/mySensors/120/0/V_LIGHT:state:MAP(switchFromMqtt.map)]"}
Switch Switch_Down             {mqtt="<[server:/mySensors/120/1/V_LIGHT:state:MAP(switchFromMqtt.map)]"}
Switch Switch_UpDown           {mqtt="<[server:/mySensors/120/2/V_LIGHT:state:MAP(switchFromMqtt.map)]"}
Dimmer Light_Dimmed   (Lights) {mqtt=">[server:/mySensors/119/0/V_DIMMER:state:*:default]"}

switchFromMqtt.map: (in transform folder)

0=OFF
1=ON 

Rules for 2-switch dimmer control (short press Switch_Up switches light on, short press Switch_Down switches light off, keep pressed to increase/decrease light level):

val Long DimmerDelayMs = 333L 

rule "DimUp"
when
  Item Switch_Up received update ON
then
  var Boolean dimmed = false
  do
  {
    Thread::sleep(DimmerDelayMs) 
    if (Switch_Up.state == ON)
    {
      sendCommand( Light_Dimmed, INCREASE )
      dimmed = true;
    }
  } while (dimmed)
  if (!dimmed) sendCommand( Light_Dimmed, ON )
end

rule "DimDown"
when
  Item Switch_Down received update ON
then
  var Boolean dimmed = false
  do
  {
    Thread::sleep(DimmerDelayMs) 
    if (Switch_Down.state == ON)
    {
      sendCommand( Light_Dimmed, DECREASE )
      dimmed = true;
    }
  } while (dimmed)
  if (!dimmed) sendCommand( Light_Dimmed, OFF )
end

Rules for 1-switch dimmer control (short press switches light on/off (depending on current state), keep pressed to increase/decrease light level):

rule "DimUpDown"
when
  Item Switch_UpDown received update ON
then
  var Boolean dimmed = false
  var Number percent = 0
  if (Light_Dimmed.state instanceof DecimalType) percent = Light_Dimmed.state as DecimalType 
  do
  {
    Thread::sleep(DimmerDelayMs) 
    if (Switch_UpDown.state == ON)
    {
      // Start cycling up/down until released
      var Boolean dimmUp = percent < 100
      do
      {
        if (Light_Dimmed.state instanceof DecimalType) percent = Light_Dimmed.state as DecimalType 
        if (dimmUp) sendCommand( Light_Dimmed, INCREASE )
        else		sendCommand( Light_Dimmed, DECREASE )
        if (percent >= 100)	dimmUp = false;
        if (percent <= 0)	dimmUp = true;
        dimmed = true;
        Thread::sleep(DimmerDelayMs) 
      } while (Switch_UpDown.state == ON)
    }
  } while (dimmed)
  if (!dimmed)
  {
    // Short press: switch on or off, depending on current state
    if (percent > 0)	sendCommand( Light_Dimmed, OFF )
    else				sendCommand( Light_Dimmed, ON )
  }
end

Rule for the dimmable light:

rule "MyDimmer0"
  when
    Item Light_Dimmed received command
  then
    var Number percent = 0
  
    if(Light_Dimmed.state instanceof DecimalType) percent = Light_Dimmed.state as DecimalType 
    if(receivedCommand==INCREASE) percent = percent + 5
    if(receivedCommand==DECREASE) percent = percent - 5
    if(receivedCommand==ON) percent = 100		
    if(receivedCommand==OFF) percent = 0		
    if(percent<0)   percent = 0
    if(percent>100) percent = 100
    postUpdate(Light_Dimmed, percent)
end

Some stuff I'm still struggling with (any help/ideas appreciated):

• Not sure if I can wrap (parts of) rules in a function to make re-use easier
• Getting the current value of an item seems complicated first testing for DecimalType, then getting it. Maybe this can be done more efficient?
• I use Thread::sleep to determine the timing of the buttons on the sensor node (pressed short/long). This will be influenced by the jitter on the sensor values received, but currently it seems to work fine. Furthermore Thread::sleep (probably) blocks whole rule processing, so this isn't a nice solution. The short/long presses can also be dermined on the sensor node and reported with different values, but then the sensor node is no longer a dumb switch and has to have knowledge of short/long presses....

[kolaf]

@Yveaux Excellent, this is just what I needed, thank you.

I started looking at your Perl script since this seems like the most active solution for openhab integration. I have a couple questions if you don't mind.

Why do you have two versions of the gateway script, and which version should I use as a basis when adding serial support?

Does your gateway take care of node ID assignments? I guess I will figure out that by reading more of code :-)

I'm thinking that I will fork your project to add a serial option to your script, controlled by some kind of commandline argument.

[Yveaux]

@kolaf said:

@Yveaux Excellent, this is just what I needed, thank you.

Glad I could help!

Why do you have two versions of the gateway script, and which version should I use as a basis when adding serial support?

The serial format changed from MySensors 1.3 (protocol 1) to 1.4beta (protocol 2). I was lazy and just cloned the 1.3 version to add 1.4 support (the 2-version). Wouldn't be hard to support both, but I really wrote this script for my own usage. It's not documented and I tried to help Damme in the past to build MQTT support. I'm primarily on 1.4b btw, with some 1.3 setup for backwards sniffer support...
If more people start using it I should do some things the nice way ;-)

Does your gateway take care of node ID assignments? I guess I will figure out that by reading more of code :-)

Not at the moment. Shouldn't be hard to implement though, but when you implement it you run into another issue of mapping the node-ID's onto the MQTT topic tree, or accessing the right topic from OpenHAB.
Sticking to fixed Node ID's seemed to make more sense to me.

I'm thinking that I will fork your project to add a serial option to your script, controlled by some kind of commandline argument.

Feel free to fork, but the current code is based on AnyEvent. Not that I like it, but it seemed to have the best MQTT support. There is some hacking in the script to get things working, for which I don't know how they behave when switching to serial.

[Yveaux]

Btw. there's one important thing to understand when using the Perl script. When it receives values from a sensor node through the gateway it's easy to publish the value in the topic-tree.
When a value has to be sent to an actuator node, the story is different as the script has to know which topic to subscribe to at the MQTT broker.
Currently when a mysensor node requests a value from the gateway the script automagically translates this into a subscription of the corresponding topic with the MQTT broker. The dimmer node for example, calls gw.request(childID, V_DIMMER) from setup to subscribe itself to dimmer messages.
Note that sometimes this request gets lost (CRC error or so) and the subscription fails. While not supported by the MySensors library, a robust implementation should wait for a response after requesting this value and retry when it doesn't come.
The Perl script stores all current subscriptions persistent (file subscriptions.storage) so restarting the Perl script will not force you to restart all nodes to subscribe again.

[Yveaux]

And another small one; an RGB dimmer!

MQTT topics (exposed by the MQTT perl script. Node 118 = 3-channel dimmable light):

/mySensors/118/0/V_DIMMER          dimmable light RED, accepting integer value between 0 and 100
/mySensors/118/1/V_DIMMER          dimmable light GREEN, accepting integer value between 0 and 100
/mySensors/118/2/V_DIMMER          dimmable light BLUE, accepting integer value between 0 and 100

Items:

Dimmer Light_R      {mqtt=">[server:/mySensors/118/0/V_DIMMER:state:*:default]"}
Dimmer Light_G      {mqtt=">[server:/mySensors/118/1/V_DIMMER:state:*:default]"}
Dimmer Light_B      {mqtt=">[server:/mySensors/118/2/V_DIMMER:state:*:default]"}
Color Light_RGB 	"RGB Dimmer" 	(Lights)

Rules to distribute colorwheel value over R,G,B dimmers:

rule "Set RGB value"
when
        Item Light_RGB changed
then
        var HSBType hsbValue = Light_RGB.state as HSBType
        postUpdate( Light_R, hsbValue.red.intValue )
        postUpdate( Light_G, hsbValue.green.intValue )
        postUpdate( Light_B, hsbValue.blue.intValue )
end

No button control here; just using the colorwheel and on/off buttons in the GUI.

Enjoy!

[Damme]

rule to calculate absolute humidity and dew point from degree Celsius and rH%

import java.lang.Math
import java.lang.Integer
import java.lang.Double


rule "Calculate absolute humidity (g h2o / m3 air) and dew point"
when
    Item temp1 changed or
    Item hum1 changed
then
    var temp = temp1.state as DecimalType
    var hum = hum1.state as DecimalType
	
    var t1 = (17.271*temp.floatValue) / (237.7+temp.floatValue) + Math::log(hum.floatValue*0.01)
    var dew = (237.7 * t1) / (17.271 - t1)
    var Number c1 = ((17.67*temp.floatValue)/(temp.floatValue+243.5))
    var abs = (Math::pow(Math::E,c1.doubleValue)*6.112*2.1674*hum.floatValue) /(273.15+temp.floatValue)
	
    Dewpoint1.postUpdate(dew)
    AbsHum1.postUpdate(abs)
end

[Yveaux]

@Damme Nice calculation example! Thanks!

[Dany]

Hi everyone!

I'm new in the topic. I find it very interesting the world of mysensors.
I would like to ask whether there is a description of someone that I can set my mqtt openHAB bindings eg .: an Arduino LED dimmer ?

I already read http://forum.mysensors.org/topic/303/mqtt broker-gateway
I made a Humidity sensor node, and Relay node, too.

It would be good if we had a basic description or example project for beginners from all sensor type. :)

[pgo]

It is not rocket science to get the openHAB running w/MQTT gateway, see for example my post with DS/Light/Relay in http://forum.mysensors.org/topic/115/implementing-multiple-sensors/60

But sure, it would be great to put a wiki with all sensor settings for openHAB together on one page. I needed to read/search for some days to put the knowledge together...

Example of the openhab screenshots on mobile https://github.com/pgo-sk/mysensors/wiki/Home-automation-using-mysensors-and-openHAB
There you see also the mapping of the sensor

[adi32k]

How can I make openhad respod to gw.request(sensor, V_HEATER_SW,0);

I have a relay actuator sketch and in setup() I have this

for (int sensor=1 ; sensor<=NUMBER_OF_RELAYS;sensor++)
{
gw.present(sensor, S_HEATER);
gw.request(sensor, V_HEATER_SW,0);
}

practically I would like openhab to respond to the gw.request with the actual state of the relay.

My item definition is the follwing. I am able to ON and OFF the relay, but I need to find a way to get the values from openhab of the relays when the relay actuator arduino reboots.

Switch Incalzire_Releu_GF_Living2 "Incalzire Releu Living 2" <heating> (Incalzire) {mqtt=">[mysensor:MyMQTT/3/2/V_HEATER_SW:command:ON:1],>[mysensor:MyMQTT/3/2/V_HEATER_SW:command:OFF:0]"}

[raditv]

is there any sample code for controlling RGB led here?

[Chaotic]

Sorry to Necro this thread but had a question,

I believe I read somewhere that you can use a serial gateway connected to a pi and have openhab/mqtt run on the pi?

How would one go about setting this up? Currently I have 2 Unos one running as the serial gateway. I plan to replace the serial gateway with a nano I'm still waiting on that.

I just got the pi last night so I'm still working on getting everything up and running on that but I'd rather just connect the gateway directly to the pi rather than have to get a wifi/ethernet module for one of the arduinos.

Also probably outside the scope of this thread (and thats fine) but anyone have a good guide for setting up the pi for openhab/MQTT?

[mhortman]

@Chaotic , Try this..
https://github.com/abouillot/HomeAutomation/tree/master/piGateway
Worked great for me

[Sweebee]

@mhortman Didn't work for me:

sudo wget http://repo.mosquitto.org/debian/mosquitto-wheezy.list~
--2015-03-27 10:46:51--  http://repo.mosquitto.org/debian/mosquitto-wheezy.list~
Resolving repo.mosquitto.org (repo.mosquitto.org)... 85.119.83.194, 2001:ba8:1f1:f271::2
Connecting to repo.mosquitto.org (repo.mosquitto.org)|85.119.83.194|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2015-03-27 10:46:51 ERROR 403: Forbidden.'

[quocanhcgd]

My house have 4 floor, i have plan build one gateway for each floor. Each floor has 4-5 sensors (temp, hum, relay, light, door, RF light). Each sensors use NRF24 to connect with gateway. Gateway connect to RAS by ethernet.
My question:

• Can i build 2 gateway mqtt connect to openhab?
  if not, what my solution to solve ?
  Thanks

[rachmat aditiya27]

you can build more than 1 gateway for that, but rather than mqtt. I think it's better to use ethernet or serial gateway because mqtt gateway has lot of problem, I tried it for months. You can forward mqtt from fhem to mosquito.