Install OH 2.5.x, MQTT 2, etc

[papa]

          Installing OpenHAB 2.5.x

  & 2.x Bindings like MQTT & Embedded MQTT Broker

Update, Feb. 4, 2020: The following thread was written from installing openHAB 2.5.0.M1, but (with a change of versions downloaded) it also worked with 2.5.0 stable & 2.5.1 stable. This thread documents how I now use backup files for a more convenient upgrade or install.

Update, Feb. 20, 2020: Seems like with the stable versions 2.5.0 & 2.5.1, MQTT Things go offline easily, requiring:  delete MQTT broker, shut down openHAB, delete userdata\mqttembedded.bin, restart openHAB, & accept MQTT broker Thing in the Inbox. (See this thread.)  I just installed stable version 2.5.2 & used backup files as in the last paragraph.

Update, March 21, 2020:  I just installed stable version 2.5.3 & used backup files as in the first paragraph of this post.

Update, April 23, 2020:  I just installed stable version 2.5.4 & used backup files as in the first paragraph of this post. As in this post, I also edited the OH start script to delete mqttembedded.bin (MQTT broker persistence) in OH's \userdata folder.

Update, Nov. 9, 2020:  I just installed stable version 2.5.10 & used backup files as in the first paragraph of this post. As in this post, I also edited the OH start script to delete mqttembedded.bin (MQTT broker persistence) in OH's \userdata folder.

After trying my previously favored way of installing (mostly .cfg text configuration files plus minimal PaperUI), I have definitely changed my mind with the 2.5.x OH versions.

I got the previously favored way to work but it was long & painful.  I don't regret it because through, that I gained information I needed to supply via PaperUI.  That information includes how to convert our configs for OH to work with our RFM69 Gateway & Node.  It should also hold true for the ESP8266 nodes.

Using mostly PaperUI takes a lot of clicking & field filling, but having the right information, it took a few hours, much faster than my previously favored way (hours & hours & hours) though that included research & tests.

In this thread, step by step, I will document what I did & my results.  Some of this may be useful to more experienced users, but I particularly want to provide details that might help beginners.

The following documentation particularly applies to our DIY Home Automation project.  It should also largely apply to other such projects that use OpenHAB.  Their main need would be to adapt their MQTT message structures into the Thing Channels.

Update, May 4, 2019: Here is an excellent video playlist introducing OpenHAB.  I recommend you start with Video 4, "Setting Up Things, Channels, & Bindings" about 30 seconds from the start.

        To Be Continued

[papa]

    Overview of the Install:

        Equipment, OpenHAB version

As I said in this thread, I started fresh on a Windows 10, 64 bit laptop.  Except from my earlier attempts, I had kept a Zulu install of Java 8.  Much of the following should work with a Linux install (including Raspberry Pi).

Using the sketch from here, I programmed a RFM69 Gateway to use Network One. Using a sketch updated from the one here (with current libraries), I programmed an RFM69 end Node 05 which combines this one with this one (using the DS18B option). So this end node has a DS18B temp sensor on Arduino D3, a DHT temp/humidity sensor on D4, a push button on D8, & a solid state relay controlled by D9.

My goal was to install an (as current & as safe as possible) OpenHAB 2 version with the 2.xx bindings of NTP, Network, & MQTT AND if possible the new embedded MQTT message broker.  I also wanted to connect the Gateway to the MQTT & by way of the Gateway connect some aspect of the end node to OpenHAB, particularly so the end nodes relay could be controlled by the node push button or the User Interface virtual switch AND the relay's Arduino pin (D9) state would be reported on the User Interface.

I did the manual installation of Windows OpenHAB latest 2.5.x stable version (there is also a manual install for Linux): I downloaded the .zip file & extracted it to C:\OpenHAB 2.5.x (<replace .x with last number of your version)  Note: As long as we do not (yet) set up OpenHAB as a service, we can have multiple folders of OH versions. We can then run & stop (one at a time) each version's start.bat or start.sh from any of the folders to find relevant information, to test, etc.

For installing, I mostly following "Recommendations for New Users" in the official documentation. Near the Recommendations... is this useful chart, which updates from time to time.  In summary as officially recommended, I used PaperUI to a greater extent than before (System, Bindings, MQTT broker, & linking) and (as also recommended) switched to text configuration files for items & sitemaps & (later) rules.

        To Be Continued with More Details

[papa]

        Oh 2.5.x Install, Part 1
        What I Did & the Results

Key:  Normal text is my commentary.  Bold is commands I entered.  Blue text is normal log text that results.  Red text is warning or error log text.

In the C:\OpenHAB 2.5.x folder, I double-clicked start.bat to run it & start openHAB. When I had the opportunity in the resulting Karaf console, I executed log:tail to see the log displayed in real time. Note: OpenHAB takes a long time to boot up the very first time. We'll want to watch our HD LED to make sure the install is still moving along. When the displayed log seemed stalled after nearly an hour, I stopped openHAB & restarted. It then made progress, like indicating the dashboards were started.

13:04:47.935 [ERROR] [org.eclipse.smarthome.core ] - bundle org.eclipse.smarthome.core:0.11.0.oh25... (102)[org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl(71)] : doFindMethod: Suitable but non-accessible method found in class org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl
                                                        Started Language Server Protocol (LSP) service on port 5007
13:55:14.237 [INFO ] [i.dashboard.internal.DashboardService] - Started Dashboard at 192.168.10.101:8080

13:55:14.299 [INFO ] [i.dashboard.internal.DashboardService] - Started Dashboard at 192.168.10.101:8443

I believe we can safely ignore the above error message as resulting from OH not being set up yet.

Note: Once OpenHAB is more set up the start.bat boot up takes less time.  Sometimes, we may need to stop OpenHAB & "clear the cache" to make changed settings work better, that is delete OH's \cache & \tmp folders.  Then the start.bat boot up will take longer, but usually not as long as the very first boot up.

Troubleshooting Update, Feb. 14, 2020: Once when I did a new install of openHAB 2.5.1 & double-clicked start.bat, the openHAB Karafe console flashed briefly & crashed.  This time I installed the JRE package of Zulu Java instead of JDK, but I believe the problem was that I had not correctly set Control Panel/System/Advanced system settings/Environment variables/JAVA_HOME correctly. I removed the JRE package & installed JDK.  Then I set JAVA_HOME to C:\Program Files\Zulu\zulu-8  In my case, this is two folders higher than the folder holding the java.exe file. Running start.bat then started openHAB just fine.

[papa]

        Oh 2.5.x Install, Part 2

If we have not chosen an OH package yet, as in the last post, the log will stop at Started Dashboard at 192.168.10.101:8443 & wait for our choice.

At my browser, I entered 192.168.10.101:8080 to go into the dashboard to choose an OpenHAB package. As I usually do, I chose (clicked on) Expert package & waited for UIs to install.

14:05:01.333 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'package-expert' has been installed.
14:05:32.642 [ERROR] [org.eclipse.smarthome.core ] - bundle org.eclipse.smarthome.core:0.11.0.oh25... (102)[org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl(54)] : bind method [setScheduler] not found
14:05:32.674 [ERROR] [org.eclipse.smarthome.core ] - bundle org.eclipse.smarthome.core:0.11.0.oh250M1 (102)[org.eclipse.smarthome.core.internal.scheduler.PeriodicSchedulerImpl(54)] : unbind method [unsetScheduler] not found
14:05:33.372 [INFO ] [.ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin
14:05:33.575 [INFO ] [marthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
14:05:34.653 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'misc-restdocs' has been installed.
14:05:34.669 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'transformation-javascript' has been installed.
14:05:34.684 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'ui-habpanel' has been installed.
14:05:34.684 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'transformation-regex' has been installed.
14:05:34.684 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'transformation-jsonpath' has been installed.
14:05:34.684 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'transformation-xpath' has been installed.
14:05:34.700 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'ui-basic' has been installed.
14:05:34.700 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'transformation-map' has been installed.
14:05:34.715 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'ui-classic' has been installed.
14:05:34.715 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'ui-habmin' has been installed.
14:05:34.715 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'transformation-xslt' has been installed.
14:05:34.715 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'transformation-exec' has been installed.
14:05:34.731 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'ui-paper' has been installed.

14:05:34.731 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'transformation-scale' has been installed.

Updated, May 4, 2019: Important, if you do NOT choose Expert package: Click on PaperUI then go to configuration/system & scroll down to Item Linking & (if not already) click off Simple Mode.  As it says there, "In simple mode, links and their according items are automatically created for new Things. If the simple mode is turned off, the user has the full control about which items channels are linked to."  Below we will create our own items in configuration text files.

[papa]

              Oh 2.5.x Install, Part 3

            Installing the OH 2.xx NTP Binding

After the above process, we can see all now available UIs at 192.168.10.101:8080/start/index

I clicked to choose PaperUI.  In Paper UI, I began to install OH 2.xx bindings:

At Addons\Bindings, enter NTP in the search box.

At Addons\Bindings\NTP, click Install.

14:10:03.707 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'binding-ntp' has been installed.
14:10:04.707 [INFO ] [ig.discovery.internal.PersistentInbox] - Added new thing 'ntp:ntp:local' to inbox.

14:10:04.707 [INFO ] [smarthome.event.InboxAddedEvent ] - Discovery Result with UID 'ntp:ntp:local' has been added.

Note: Sometimes when we click Install it just "spins."  We can check for the above log text in the Karaf console. If the Binding install is done, we refresh Addons\Bindings\ to clear the "spinner."

Note: As each binding is installed, it shows up in PaperUI\Configuration\Binding

[papa]

            Oh 2.5.x Install, Part 3

        Accepting the OH 2.xx NTP Thing

                & Its Channels

From the above process, the PaperUI Inbox should indicate it has something new added (that is the NTP Thing).

Note: Sometimes, we do something in PaperUI & we don't see all the results that we expect (like the NTP Thing). Often refreshing PaperUI shows more current configuration info, such as in the Inbox.

In PaperUI, go to the Inbox & see "Local Time NTP Server"  To accept it, click on its check mark that you should see in a blue disc.

14:10:04.707 [INFO ] [ig.discovery.internal.PersistentInbox] - Added new thing 'ntp:ntp:local' to inbox.

14:10:04.707 [INFO ] [smarthome.event.InboxAddedEvent ] - Discovery Result with UID 'ntp:ntp:local' has been added.

14:13:47.885 [INFO ] [smarthome.event.InboxRemovedEvent ] - Discovery Result with UID 'ntp:ntp:local' has been removed.
14:13:48.010 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'ntp:ntp:local' changed from UNINITIALIZED to INITIALIZING
14:13:48.197 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'ntp:ntp:local' changed from INITIALIZING to ONLINE

Note: In the log & on PaperUI, we want to see "ONLINE."  We may also see various warnings & errors for an OH element, but if it has "ONLINE," we are probably OK there.

In PaperUI, go to Configuration\Things\Local Time & see 2 channels listed.

See also that each channel has a blue disc with white inner circle. After we create related .items later, we will click a white circle to link a Thing's channel to its appropriate item.

        To Be Continued

[papa]

            Oh 2.5.x Install, Part 3
    Installing the OH 2.xx Network Binding

In PaperUI, go to Addons\Bindings\Network.     Click on Install

14:18:31.327 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'binding-network' has been installed.

[papa]

            Oh 2.5.x Install, Part 4
        Accepting the OH 2.xx Network Thing
                & Its Channels

From the above process, at least for me, no automatic Thing arrived in the Inbox.  Then I used PaperUI\Inbox\Search for Things\Network Binding.  It just spins or gets no results.

What then?  Click on Add Manually.  You should see two listings. click on the second listing: Pingable Network Device.  For the following you need to know the IP address of your local network's router.

In the field Pingable Network Device\Hostname or IP, enter your router's IP. (Mine is 192.168.10.1) Click the check mark in a blue disk to save.

Note: Pingable Network Device should show in PaperUI\Configuration\Things. Click on its gray disc to see the channels to link after suitable items are created later.

14:26:13.440 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'network:pingdevice:76a2293c' changed from UNINITIALIZED to INITIALIZING

14:26:14.034 [WARN ] [clipse.smarthome.io.net.exec.ExecUtil] - Execution failed (Exit value: -559038737. Caused by java.io.IOException: Cannot run program "arping" (in directory "."): CreateProcess error=2, The system cannot find the file    <<  disregard for Windows, does not apply.

14:26:14.034 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'network:pingdevice:76a2293c' changed from INITIALIZING to ONLINE
14:26:14.065 [INFO ] [nternal.dhcp.DHCPPacketListenerServer] - DHCP request packet listener online

14:26:14.112 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'network:pingdevice:76a2293c' has been updated.

Note that network:pingdevice is assigned a random identification of 76a2293c.

      Next, Installing the Embedded MQTT Broker

[papa]

            Oh 2.5.x Install, Part 5
        Installing the Embedded MQTT Broker

At least for now, the MQTT 2.xx Binding (as well as the MQTT 1.xx Binding) is supposed to also work with our old friend the Mosquitto MQTT message broker.  However, on Windows, Mosquitto can be a pain to install & who knows when the MQTT 1.xx Binding will be deprecated.  A reasonable to install, embedded MQTT broker could be nice.

Go to PaperUI\Addons\Misc\Embedded MQTT Broker  & click Install.

Somewhere in there (edit, configure?), I believe I entered a host or IP address of 127.0.0.1

14:31:16.654 [WARN ] [er.internal.EmbeddedBrokerServiceImpl] - Embedded broker offline - Reason unknown disregard
14:31:16.889 [WARN ] [.moquette.spi.impl.SessionsRepository] - Session does not exist. CId=RFM_gateway

14:31:16.889 [WARN ] [.moquette.spi.impl.SessionsRepository] - Session does not exist. CId=RFM_gateway

            ^^ Warnings that are safe to disregard ??

14:31:16.920 [INFO ] [o.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '127.0.0.1' with clientid embedded-mqtt-broker and file store 'C:\OPENHA~2.M1_\userdata\mqtt\127.0.0.1'
14:31:16.967 [WARN ] [.moquette.spi.impl.SessionsRepository] - Session does not exist. CId=embedded-mqtt-broker
14:31:16.982 [WARN ] [.moquette.spi.impl.SessionsRepository] - Session does not exist. CId=embedded-mqtt-broker
14:31:17.107 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'misc-mqttbroker' has been installed.

Nothing shows in inbox or via search, but my RFM69 Gateway was connected & MQTT LED is on.  (I may have forgotten to try refreshing PaperUI for Thing to appear in Inbox.)

I checked Configuration\Services\MQTT\MQTT Embedded Broker\Configure. Nothing needed changing.

Apparently a bit later, at the PaperUI Inbox: Accept Thing System MQTT Broker

        ?? After thing accepted
14:43:33.964 [INFO ] [ig.discovery.internal.PersistentInbox] - Added new thing 'mqtt:systemBroker:embedded-mqtt-broker' to inbox.

14:43:33.995 [INFO ] [smarthome.event.InboxAddedEvent ] - Discovery Result with UID 'mqtt:systemBroker:embedded-mqtt-broker' has been added.

        Next, Installing the MQTT 2.xx Binding

[papa]

            Oh 2.5.x Install, Part 6
        Installing the MQTT 2.xx Binding

Go to PaperUI\Addons\Bindings\MQTT Click on Install

14:43:34.152 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'binding-mqtt' has been installed.

14:45:51.186 [INFO ] [smarthome.event.InboxRemovedEvent ] - Discovery Result with UID 'mqtt:systemBroker:embedded-mqtt-broker' has been removed.
14:45:51.373 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'mqtt:systemBroker:embedded-mqtt-broker' changed from UNINITIALIZED to INITIALIZING
14:45:51.405 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'mqtt:systemBroker:embedded-mqtt-broker' has been updated.

14:45:51.405 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'mqtt:systemBroker:embedded-mqtt-broker' changed from INITIALIZING to ONLINE

        Here we see how the MQTT Broker continues to come online ^^ after the MQTT 2.xx Binding is installed.

Note: From the above process, I don't believe a Thing arrived in the Inbox probably because our input (see next post) is needed.

        Next, Creating a Thing for the MQTT 2.xx Binding

[papa]

                    Oh 2.5.x Install, Part 7

        Create/Install a Thing for the MQTT 2.xx Binding

Update March 6, 2019: In the following, I create a Thing for each RFM69 Node. Then within that Thing, I create a channel for each of the node's devices.  See this thread, where Joshua used a different approach.  See this post, where I discuss the possible advantages & disadvantages of each approach.

In PaperUI, progressively click on Inbox...SEARCH FOR THINGS...MQTT Binding...Add Manually...Generic MQTT Thing

As here ^^, we must choose which type of Thing for the MQTT 2.xx Binding.  All but one type are standards that may fit a standard used on our physical device.  For physical devices (like our RFM69 Nodes) which don't match the listed standards, we use the Generic Thing & configure the Thing with the message standard used on our device.

    Configure the Generic MQTT Thing  using the following fields:
Name [starts as Generic MQTT Thing]  Node05                         << This is the RFM69 Node to be accessed.
Thing ID [ 987638e9 first time ] 01e818a9 [ randomly generated ?? ]
Location BaseFR [Thing's location on which tab of PaperUI\Control ]

Bridge Selection  MQTT Broker - mqtt:systemBroker:embedded-mqtt-broker

Update, Feb. 15, 2019: I first thought "Location" just meant a physical location we could assign for our convenience. No, that will display the Thing on the named tab in PaperUI where we can see channel data or click a virtual switch.  The tabs are another User Interface for display & control, but probably not very practical to use.

         ^^ If we install Mosquitto or other for the broker instead of embedded broker, I believe that will show in the Bridge Selection drop down list.

     Click the Thing's check mark in a blue disc

14:45:51.373 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'mqtt:systemBroker:embedded-mqtt-broker' changed from UNINITIALIZED to INITIALIZING

                                        ^^ since the Generic Thing is connecting, the broker is reinitializing ??

14:45:51.405 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'mqtt:systemBroker:embedded-mqtt-broker' has been updated.
14:45:51.405 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'mqtt:systemBroker:embedded-mqtt-broker' changed from INITIALIZING to ONLINE
15:08:44.600 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'mqtt:topic:01e818a9' changed from UNINITIALIZED to INITIALIZING
15:08:44.632 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'mqtt:topic:01e818a9' changed from INITIALIZING to ONLINE

                                                                                                ^^ topic uses its random ID #, not the name

        Next, Add a Channel to the Node05 Generic Thing

[papa]

                Oh 2.5.x Install, Part 8A
        Add a Channel to the Node05 Generic Thing

For the first Node05 Channel to create, I chose device 16, the Actuator, the Arduino pin that toggles the attached relay/LED on & off. I chose this because it not only communicates its state. It also can be commanded to change state.

Notes: Under their Thing, Channels are listed in the order of their creation, not their numeric order. (We may be able to rearrange them later by editing the \userdata\jsondb\xxxThing.json file.) Most Channel fields must be filled before we can save the channel.  Clicking on "Show more" within the Add Channel window opens more fields, incl formatting.

Go to PaperUI\Configuration\Things\Node05 To Add a Channel, Click on the "+" in a blue disc beside "Channels"

        In the Add Channel Window, fill the fields:

Channel type On/Off switch    < choose type according to the item data type we want

Channel id Node05Channel16  < arbitrary ? as long as we match in a linked item later

Label Node05_Switch  < arbitrary ?

MQTT State Topic home/rfm_gw/nb/node05/dev16

Command Topic home/rfm_gw/sb/node05/dev16

Custom On/Open value 1         < [one]

Custom Off/Closed value 0         < [zero]

   ^^ After the above is saved, Channel16 (ready to link) shows under Node05 Thing.

   In the MQTT 1.xx method, the item was as below.  Note the highlighted sections that now transfer to the channel topics.

Switch Act_Node05 { mqtt="<[mosquitto:home/rfm_gw/nb/node05/dev16:state:default::]", mqtt=">[mosquitto:home/rfm_gw/sb/node05/dev16:command:*:default]" }

Note that I used the node id (Node05) & the device id (dev16) to create the Channel id Node05Channel16.

   

15:32:00.689 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'mqtt:topic:01e818a9' has been updated.

Note: What is the source of the State Topic & the Command Topic above?  In the RFM68 Gateway Sketch, (subscription topic) subTopic = "home/rfm_gw/sb/" & the Node ID like Node05 & Device ID like dev16 are added on the end. (Publish topic) pubTopic = "home/rfm_gw/nb/"

        Next, Create Another Item to Link to the Channel

[papa]

                    Oh 2.5.x Install, Part 8B
        Add Another Channel to the Node05 Generic Thing

For the next Node05 Channel to create, I chose device 02, RSSI, radio signal strength, which Node05 is already programmed to send. It only communicates its state.

Go to PaperUI\Configuration\Things\Node05  To Add a Channel, Click on the "+" in a blue disc beside "Channels"

        In the Add Channel Window, fill the fields:
Channel type Text Value < choose type according to the item data type we want
Channel id Node05Channel02 < arbitrary ? as long as we match in a linked item later
Label Node05_RSSI < arbitrary ?

MQTT State Topic home/rfm_gw/nb/node05/dev02

^^ After the above is saved, Channel02 (ready to link) shows under Node05 Thing.

    In the MQTT 1.xx method, the item was as below. Note the highlighted sections that now transfer to the channel topics.

String Node5Rssi "Base_FR_05_RSSI (db)[%s]" <network> (Nodes) {mqtt="<[mosquitto:home/rfm_gw/nb/node05/dev02:state:default]" }

        Next, Create Items to Link to the Channels

[papa]

               Oh 2.5.x Install, Part 9
        Create Items to Link to the Channels

        For the NTP, Network, & Node05 Things

So far, we've used PaperUi to configure OpenHAP.  Now we will use text files to configure Items (as we will later do with Sitemaps & Rules).  We could create only one .items file, but as it fills up that can make it hard to find & edit items as needed.  Better to create more than one .items file.

In OpenHAB's \conf\items folder, create a file named Time.items & within Time.items create this entry & save the file:

DateTime Date "Date & Time [%1$tm.%1$td.%1$tY %1$tr]" <calendar> { channel="ntp:ntp:local:dateTime" }

If you look at the Thing & Channels created via this post, you'll see the channel highlighted above ^^.

In OpenHAB's \conf\items folder, create a file named Network.items & within Network.items create these entries & save the file:

Group Gateways // Gateways, Router

Switch Router_Active "Router [%s]" <network> (Gateways) { channel="network:device:192_168_10_1:online" }
Number RouterResponseTime "Router Response Time [%.2f]" <network> (Gateways) { channel="network:device:192_168_10_1:latency" }

If you look at the Thing & Channels created via this post, you'll see the channels highlighted above ^^.

In OpenHAB's \conf\items folder, create a file named Node05.items & within Node05.items create these entries & save the file:

Switch Node05Sw "Node05Sw" { channel="mqtt:embedded-mqtt-broker:topic:mything:Node05Channel16" }

String Node05RSSI "Node05rssi (db)[%s]" <network> (Nodes) { channel="mqtt:embedded-mqtt-broker:topic:mything:Node05Channel02" }

If you look at the Channels created starting at this post, you'll see the channels highlighted above ^^.

15:39:17.208 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'network.items'
15:39:17.614 [INFO ] [thome.event.ItemChannelLinkAddedEvent] - Link 'Router_Active-network:device:192_168_10_1:online' has been added.
15:39:17.645 [INFO ] [thome.event.ItemChannelLinkAddedEvent] - Link 'RouterResponseTime-network:device:192_168_10_1:latency' has been added.
15:39:17.677 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'Node05.items'
15:39:17.708 [INFO ] [thome.event.ItemChannelLinkAddedEvent] - Link 'Node05-mqtt:embedded-mqtt-broker:topic:mything:Node05Channel16' has been added.
15:39:17.739 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'Time.items'
15:39:17.755 [INFO ] [thome.event.ItemChannelLinkAddedEvent] - Link 'Date-ntp:ntp:local:dateTime' has been added.
15:39:18.020 [INFO ] [smarthome.event.ItemStateChangedEvent] - Date changed from NULL to 2019-01-30T15:39:19.389-0500

            In the log text above ^^, note the Links that were created.  Now we need to connect them.

        Next, Link Channels to Matching Items

[papa]

          Oh 2.5.x Install, Part 10A
        Link Channels to Matching Items

Do NOT miss this step which makes the link to complete the chain from service or physical device (like our RFM69 Nodes) to OpenHAB. We are back to using the PaperUI for this.

Go to PaperUI\Configuration\Things\Pingable network device    Click blue disk with white circle

    Complete fields in Link channel window
Please select a profile: Default (system:default)
Please select the item to link: [drop down list] Router (Router_Active)      click Link

15:58:19.080 [INFO ] [thome.event.ItemChannelLinkAddedEvent] - Link 'Router_Active-network:pingdevice:76a2293c:online' has been added.
15:58:20.033 [INFO ] [smarthome.event.ItemStateChangedEvent] - Router_Active changed from NULL to ON

Go to PaperUI\Configuration\Things\Pingable network device\Latency   click blue disk with white circle

    Complete fields in Link channel window

Please select a profile: Default (system:default)
Item to Link: Router Response Time (RouterResponseTime)      click Link

16:01:18.004 [INFO ] [thome.event.ItemChannelLinkAddedEvent] - Link 'RouterResponseTime-network:pingdevice:76a2293c:latency' has been added.

16:01:19.082 [INFO ] [smarthome.event.ItemStateChangedEvent] - RouterResponseTime changed from NULL to 179.0

Go to PaperUI\Configuration\Things\Local Time    Click blue disk with white circle

    Complete fields in Link channel window
Please select a profile: Default (system:default)
Please select the item to link: [drop down list] DateTime (Date)      click Link

        Next, Link More Channels to Matching Items

[papa]

              Oh 2.5.x Install, Part 10B
        Link More Channels to Matching Items

Go to PaperUI\Configuration\Things\Node05\Node05_RSSI    Click blue disk with white circle

    Complete fields in Link channel window
Please select a profile: Default (system:default)
Please select the item to link: [drop down list] Node05rssi (String)    click Link

Go to PaperUI\Configuration\Things\Node05\Node05_Switch    Click blue disk with white circle

    Complete fields in Link channel window
Please select a profile: Default (system:default)
Please select the item to link: [drop down list] Node05sw (Switch)     click Link

        Next, Display Items on User Interface

[papa]

                 Oh 2.5.x Install, Part 11
        Create Sitemap to Display Items on User Interface

In OpenHAB's \conf\sitemap folder, create a text configuration file named My.sitemap.

        In My.sitemap, add these entries & save the file:

sitemap My label="My House"

{
Group item=Gateways label="__Gateways Info__" icon="signal"

    Frame {
        Text item=Router_Active
        Text item=RouterResponseTime

        Switch item=Node05Sw
        Text item=Node05RSSI

    }

    Frame {Text item=Date}

}

[papa]

           Oh 2.5.x Install, Part 12
        Display Items on a User Interface

If your computer hosting OpenHAB has an IP of 192.168.10.101 (below adapt to your computer's IP)

In your computer's browser address box, enter 192.168.10.101:8080/basicui/app?sitemap=My

You should see a User Interface (UI) that displays the changing values of the items. If the UI does not update as expected, stop OpenHAB & restart it before trying the UI again.

The following works at least if the host computer is Windows & another computer on the local network is Windows AND both Windows computers are in the same Workgroup & both have network discovery tuned on:

    If OpenHAB is set up & working on a host computer, then one can enter the same in the address box of ANOTHER Windows computer & the UI should also display on that second computer.

Note, from some experience, I believe the following is still true: All or most OpenHAB configurations may be viewed in PaperUI. However, we can only use PaperUI to change what we create in UI. To change what we create in text configuration files, we much edit the text files.

    Next, Compare & Evaluate Configuration Methods

[papa]

            Comparing & Evaluating:
            All Text Configuration vs
    Much PaperUI & Some Text Configuration

Before ... (perhaps with some struggles, I could install Mosquitto MQTT message broker.   In OpenHAB's conf\services folder, I could create addons.cfg with entries to set up the package, bindings, actions, transformations, etc. Then running OpenHAB generated network.cfg, mqtt.cfg, etc. Completing a few lines in the .cfg files & running OpenHAB further configured it. Into \conf\items & \conf\sitemap, I could copy .items files & a sitemap file. I could then call up the User Interface in the browser.

Now, in PaperUI, we must click to add each Binding, Service, etc. Then we must click through & fill various fields to configure one or more Things for each binding, then one or more Channels for each Thing. Then we create the .items in a text file. Then we click to link each item to a Channel. Then we create a .sitemap text file & display it in a User Interface.

The main thing is the current process starting with much PaperUI works & the former process no longer works very well. The current process can be tedious with much clicking & filling fields.  It's good that the current approach has an embedded MQTT broker that we can install with a few clicks & entries.  We can avoid the install of our old friend the Mosquitto MQTT broker.  The current process with MQTT 2.xx binding works & works with our RFM69 Gateway & end nodes using the Generic Thing that we configure to be compatible with our RFM69 devices.  If the MQTT 1.xx binding goes away, we can be ready to move on.

All the PaperUI configuration is stored in OpenHAB's \jsondb folder.  I believe we might directly create & edit some configurations there, such as in the xxxxThings.json. file.  However, be careful.  Each Thing & its channels has several fields & brackets to track.  If we try this, I recommend saving a backup file.

I hope the above helps you understand & to utilize OpenHAB 2's latest features & approaches.

[papa]

            Annoying Feature of OH 2.5.2 ??
             Sitemaps Resist Refreshing ??

Awaiting response, I've posted the following at OpenHAB Community & may later post an issue at the github:

Once OH 2.5.2 loads a sitemap, OH2.5.2’s storage of the sitemap seems to resist changing, even when one stops OH, clears the cache & restarts OH. One can edit a sitemap & save it, but then the log does not necessarily show "refreshing model ‘xxx.sitemap’ & likewise does not necessarily show a change on the UI. It may take several stop, clear cache, restarts before a sitemap change 'takes.'

The quickest way to get a sitemap change to register seems to be copying a changed sitemap's contents into a brand new .sitemap file. That forces OH2.5.2 to refresh the sitemap. (Inconvenient in its own way)

Does anyone else notice this behavior in OH2.5.2?

[papa]

Today I installed stable version 2.5.3 & used backup files as in the first paragraph of this thread's first post. I will see if sitemaps resist refreshing as happened with version 2.5.2.

[papa]

        Annoying Feature of OH 2.5.2 AND OH 2.5.3 ??
            Sitemaps & Habpanels Resist Refreshing ??

Awaiting response, I've posted the following at OpenHAB Community & may later post an issue at the github:

Once OH 2.5.2 loads a sitemap, OH2.5.2’s storage of the sitemap seems to resist changing, even when one stops OH, clears the cache & restarts OH. One can edit a sitemap & save it, but then the log does not necessarily show "refreshing model ‘xxx.sitemap’ & likewise does not necessarily show a change on the UI. It may take several stop, clear cache, restarts before a sitemap change 'takes.'

The quickest way to get a sitemap change to register seems to be copying a changed sitemap's contents into a brand new .sitemap file. That forces OH2.5.2 to refresh the sitemap. (Inconvenient in its own way)

        ^^ This annoying behavior continues with OH 2.5.3, affecting Habpanels as well as Sitemaps.

Does anyone else notice this behavior in OH2.5.2 & OH 2.5.3 ?

[papa]

            Annoying Feature of OH 2.5.2 AND OH 2.5.3 ??
             Sitemaps & Habpanels Resist Refreshing ??
                                An Annoying Fix

Running OH 2.5.3, some sitemap/habpanel items were working & others that worked before were not working. The logs showed many errors.  Clearing the cache did not seem to help much. 

Using backup.bat in openHAB's \runtime\bin folder, I backed up my OH 2.5.3 configurations. Then I made a fresh install of OH 2.5.3. I used restore.bat to copy in my OH 2.5.3 configurations. The first time I ran the new OH 2.5.3, not all Things came online (esp. the MQTT embedded broker & many Things depending on it). So I stopped openHAB. I deleted OH 2.5.3's \userdata\cache & \userdata\tmp folders & \userdata\mqttembedded.bin. I restarted OH. After running a while, OH log errors cleared & sitemaps & habpanels seem to be working.

Though for a while the following message stayed at the bottom of sitemaps (on both computer hosting OH & via OH Cloud): "SSE subscription failed: running in fallback mode. After a while, that message cleared. Now it appears intermittently & so does "Offline: waiting for connection to become available" Maybe some of this is Corona Virus related: all that extra streaming & working from home.

The above is a drastic, annoying fix. However, it may take less time & be more effective than constantly stopping OH, "clearing the cache," restarting & still having sitemap/habpanel gliches.

I wonder: "Are these problems due to OH 2.5.2 & OH 2.5.3 or due to the growing complexity of my OH configs?"

I believe OH 2.5.1 worked better, but I'll test that via a fresh install of OH 2.5.1 plus the config backup I made from OH 2.5.3.

       Next Test of OH Installs

[papa]

                    Next Test of OH Installs
        OH 2.5.1 plus config backup from OH 2.5.3

OH 2.5.1's initial display of log:tail in the Karaf seems a bit cleaner than later versions. However, it still took at least 3 cache clears/restarts & some waiting to get all sitemaps/habpanels populated.

Maybe OH 2.5.1 works slightly better than 2.5.2 & 2.5.3.  Since so far I found no advantages for me in 2.5.2 & 2.5.3, I'll stick with 2.5.1 for a while or perhaps try 2.5.0 again.

However, (without showing in the logs), "SSE subscription failed: running in fallback mode" is back at the bottom of sitemaps on BasicUI.  See this thread: Seems this issue has been around.

Later update: Still testing OH 2.5.1 with backup configs from OH 2.5.0.M1 & later versions up to OH 2.5.3.At one point, I tried 2 cache clears/restarts & many sitemap/habpanel items were not populating.  Then I tried only deleting mqttembedded.bin in OH's /userdata folder & restarting.  (Coincidence ?) sitemap/habpanel items populated.   Bottom of UI sitemaps still show "SSE subscription failed..." 

[papa]

        Another Annoyance of Later OH versions
        Three OpenWeatherMap Things, Not Two

OpenWeatherMap Account is one Thing needed. A Weather and Forecast Thing (using the account) is also needed. I have both of these with items linked to Weather and Forecast channels. I also had (but deleted) A Local Weather and Forecast Thing (also using the account) with the same channels as the Weather and Forecast Thing. However when I deleted the duplicate Thing, it showed up again in the Inbox.

I removed the Local Weather and Forecast Thing from the Inbox.

When I refreshed the Inbox the Local Weather and Forecast Thing reappeared.  To the Local Weather and Forecast Thing, I applied the ignore button (eye icon with slash through it) to prevent me from accepting it again.  Maybe the duplicate Thing will go away after a future OH restart.

Or maybe the Local ... Thing is now the official name of that Thing, but my backup has the Thing with an older name.  I'd prefer not to switch Weather & Forecast Things since I have many items linked to Weather and Forecast channels.

[papa]

        More Tests of OH versions

I did more testing of OH 2.5.1 with backup configs from OH 2.5.0.M1 & later versions up to OH 2.5.3. At one point, I tried 2 cache clears/restarts & many sitemap/habpanel items were not populating. Then I tried only deleting mqttembedded.bin in OH's /userdata folder & restarting. (Coincidence ?) sitemap/habpanel items populated. Bottom of UI sitemaps still show "SSE subscription failed..."

I went back to OH 2.5.3 with backup configs from OH 2.5.0.M1 & later versions up through OH 2.5.3. Before starting OH 2.5.3, I again tried only deleting mqttembedded.bin in OH's /userdata folder. Again sitemap/habpanel items populated. Bottom of UI sitemaps still show "SSE subscription failed..." Will see if this latter issue goes away later.

My Zulu Java 8 was fairly up to date, but I updated to the latest, Zulu JDK 8.44.0.11 (8u242).

Update: "SSE subscription failed..." seems to have left from the bottom of sitemaps.

[papa]

                Update

    As indicated in the approaches of this post above, ...

I had installed & been running OH 2.5.4 mostly successful since April 23, 2020.

Today, I updated to OH 2.5.10 & it seems to be working fine so far (except needing to restart OH so its sending emails works).