My discoveries with OH 2 and MQTT 2

[Joshua]

Building off of Papa's contribution Reply Install OH 2.5.0.M1, MQTT 2, etc, here's my approach and what I've found.

I completed part 7 in papa's thread with a Thing called RFM Nodes.

Each subsequent channel includes all of my devices for each node.

i.e. Node50Mot Node 50 dev 41 Motion Sensor  home/rfm_gw/nb/node50/dev41

[Joshua]

So far all of my nodes are passive, monitoring, nodes only. There are MQTT state topics and no commands. Most of my channel types only work with a string type selected. Battery (dev04) and Humidity (dev49) work with a channel type of number selected. Motion (dev41), RSSI (dev02), Temperature (dev42), and Contact (dev46) work with a channel type of string selected.

Feel free to use my 3in1 sensor as an example of how to put yours together. //I'm building a new version and will post this build here.

/* Living Room 3 in 1*/
//RSSI
String Node50RSSI "Living Room RSSI [%s db]" <network> (All,NodeHealth) { channel="mqtt:topic:0a345c06:Node50RSSI" }
//Date Time Last Update
DateTime Node50DaTi "Living Room Last Update [%1$tm/%1$td, %1$tI:%1$tM %1$tp]" <datetime> (All,NodeHealth)
//Battery
Number Node50Volt "Living Room [%.2f Vdd]" <battery> (All,NodeHealth,LiPoBat,Node50Volt_Chart) { channel="mqtt:topic:0a345c06:Node50Volt" }
//Humidity
Number Node50Hum "Living Room Humidity [%s %%]" <hum_icon> (All,InsideCond) { channel="mqtt:topic:0a345c06:Node50Hum" }
//Motion
String Node50Mot "Living Rm Motion [MAP(motion.map):%s]" <motion1> (All,InsideCond) { channel="mqtt:topic:0a345c06:Node50Mot" }
//Temperature
Number Node50Temp "Living Room Temp [%.1f °F]" <temperature> (All,InsideCond,Node50Temp_Chart) { channel="mqtt:topic:0a345c06:Node50Temp" }

Later I'll elaborate on these node that are used for charting.

//Battery Chart
Group Node50Volt_Chart
//Battery Period
Number Node50Volt_Per "Living Rm Battery Period"//Temperature Chart
Group Node50Temp_Chart (temperature)
//Temperature Minimum
Number Node50Temp_Min "Living Rm Temperature Minimum [%.0f °F]" <temperature> (All,Node50Temp_Chart)
//Temperature Maximum
Number Node50Temp_Max "Living Rm Temperature Maximum [%.0f °F]" <temperature> (All,Node50Temp_Chart)
//Temperature Average
Number Node50Temp_Ave "Living Rm Temperature Average [%.0f °F]" <temperature> (All,Node50Temp_Chart)
//Temperature Period
Number Node50Temp_Per "Living Rm Temperature Period"

[Joshua]

My motion node has a motion.map to change the GUI to show customized text.

//Motion
String Node50Mot "Living Rm Motion [MAP(motion.map):%s]" <motion1> (All,InsideCond) { channel="mqtt:topic:0a345c06:Node50Mot" }

In Paper UI, select Add-ons -> Transformations -> and install Map Transformation

Create and Save a file named motion.map in the \openHAB-conf\transform\ folder. Put the following lines into it.

OFF=Still
ON=Motion
NULL=unknown
-=initializing

[papa]

Nice, complete write-up, Joshua, which confirms how OH 2.5.0.M1, MQTT Binding 2.xx & the Embedded Broker are workable.

     I noticed you are using & demonstrating a way to create channels that is an alternative to my approach.

I have been creating a Thing for each RFM69 node & then creating channels for each node device within that Thing. You created one Thing called RFM Nodes & then within that Thing, you have been creating channels for ALL your RFM69 nodes. Apparently both ways work & each probably has some advantages & disadvantages. A PaperUI feature influences results: PaperUI\Configuration\Things sort in alphabetical order. However, under their Thing, channels list in the order of when they were created.

Your way would reduce some of the currently (but possibly changing) tedious clicking & field-filling in PaperUI to create multiple RFM69 Things. Your way produces one list of nodes/devices that can be scrolled through. Depending on how many nodes & node devices you have, your way may produce a very long list. By the PaperUI feature above, if you later add a device/channel to a node, that channel could list much later in the channel list than other channels for that node.

My way keeps a node's channels together even if a device/channel is added later. Some of my nodes have many device/channels which makes a fairly long list by itself & all my RFM69 node channels together could be a long, confusing list, especially if I added a node channel later.  Creating one Thing for each node avoids this, but endures the tedious clicking & field-filling in PaperUI.  PaperUI Next Generation may improve on this.

Thank you.  It is good you are showing another way to create/organize channels. For the reasons above & for the time being & in most cases, I believe I will create a Thing for EACH RFM69 node. However, for nodes (including ESP8266) that have one or very few devices, I may consider grouping them under a Thing that categorizes them together (like ECOplug).

In part 7 of my OH 2.5.0.1 thread, I put a link to the thread above.