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