I’m force-fitting OpenHAB2 to interface to my home-built system that centers around an Arduino running a DIY thermostat and pin-control sketch. In thinking about how a client browser can be updated with changes, I am very determined to avoid polling by the client browser in favor of “server pushing”, if you will. My current understanding is that bindings are tools for server-to-device whatnots rather than tools for browser communications. Can you direct me to documentation on how to construct an AJAX-like or sockets-based link from widget displayed text in the user’s browser to Ubuntu OpenHAB2 server daemon in the DIY scenario of mine? I already have good monitoring operation using the polling method in Paper UI and HABPanel UI. I want to get away from polling. My suspicion is that I’ll need to get away from Paper UI and instead establish the sockets link to a HABPanel widget because I also need the controls, like to change thermostat settings or Arduino pins, to be available. Note also that the Arduino is USB connected to my rack-mount server, just so you can understand the local layout. I’ve spent a few hours searching, but not finding the documentation I need. Thank you!
[EDIT] I prefer to do this without the point-of-failure of a MQTT broker.
[EDIT] Looks like SSE is what I need to look at…
dashing based dashboard (https://github.com/smar000/openhab-dashboard) may be the UI I’ll have to install…
If I do have to install another UI, it might instead be Grafana, since dashing would require me to install ruby-dev which is no longer available for me to install on my unsupported Ubuntu version.
If I understand correctly, what you are looking for is to bypass OH and just show information in the OH UI (sitemap or HABPanel). If that isn’t the case then the proper way to integrate something like this is to:
Your Arduino device publishes data somehow
An OH binding receives that data somehow
The OH Binding populates one or more Items with the received data
The Items are represented on the OH GUI
The Items are saved to a database
To go the other way
User changes a Widget in HABPanel or the sitemap
Changes cause a command on the Item
The Item changes state
The command gets picked up by the OH Binding
The OH Binding publishes the command somehow
The Arduino receives the command somehow
So, if you are wanting to integrate this device with OH, then you need to be focusing on that binding part that sets up the two-way communication between your device and OH itself. Once you represent your device’s sensors and actuators as Items within OH, then the native UI stuff just works.
If you do not use Items, then all you will be doing is setting up a UI that completely bypasses OH, in which case you may as well set up your own server with a web UI and just include that UI on your HABPanel or Sitemap using a Frame widget or Webview element repsectively. You will also be losing out on the ability to use the sensor data or control your device from OH Rules (e.g. activate or change a parameter on the device in response to some other sensor using another technology).
FWIW, I’ve run lots and lots of servers over the years. I’ve never seen a more stable and reliable server than the two MQTT brokers I’ve run (Mosquitto and RabbitMQ).
Thank you Rich! I’m working hard at reading what you wrote to get a meeting of the minds, but seriously having to refocus my efforts for a few days to winterizing the exterior of my house.
(The “point-of-failure” term was more connected with non-transparent upgrades, package [non-]availability in repositories, and learning curve/configuration TIME and effort that contributes to impending system downtime rather than with final operational reliability of a perfectly-configured package. Admittedly, this is based on my general experiences with other software packages. To be honest with myself, it may be more of a factor that I prefer to minimize using a package in favor of writing my own code when functionality is as simple as text message transport…it’s probably a self-actualization or therapy thing for me, and my needs are simple enough that OS upgrades don’t break anything with the notable exception of init system changes threatening my crontab configurations.)
Ah, but there is the rub. There is almost nothing simple about text message transport as soon as you start to encounter any of the many many edge cases. In the long run I’ve found it to be a much better use of my time to learn and use a dedicated system for this than trying to code my own.
To each his own, but I can say that MQTT with Mosquitto is by far the most common approach, not just here on OH but with all the home automation systems I’m aware of.
You should review the Beginner’s Tutorial and Concepts chapter of the User’s Guide to get a better understanding of how OH works. Almost all that I said above is just a high-level explanation of how OH works and isn’t really specific to your situation.
For reasons related to my past experiences and trick questions in college, the user-level documentation doesn’t clearly nail down enough of the concepts to enable me to get developer-level integration with my home-built system. I’m confident it will come by experimentation. But know that I am honored to have the thoughts you’ve given.
Perhaps they will not take you all the way, but if you have a lack of understanding some of the basics of how OH works, information that is contained in the docs, it will be exceptionally difficult even for us to help you. Your original question shows a very significant lack of knowledge of how OH works.
I already have a certain level of communication as I tried to say above, “…I already have good monitoring operation using the polling method in Paper UI and HABPanel UI…” What i’ve done is install exec binding which gave me a working “Thing” that successfully launches by client polling action a server shell script and successfully displays the server script results in client browser. That much is working for me. I had wanted the same activity done with SSE instead of polling.
In the meantime, I learned of “long polling” which I did not know about before. I’ve also since learned that the OH2 Developer Guide page “Technical Difference to openHAB 1” states “the REST API does not support websocket access anymore - it actually completely drops “push” support and only has a simple long-polling implementation to provide a basic backward-compatibility for clients.” I understand, maybe incorrectly, that the quoted statement, by using the word “completely” is saying not only that WebSockets, but also SSE on the OH2 side is no longer supported as it was in OH1. I suspect that the reason for this is because SSE development in Eclipse is not fully stabilized, but regardless, I would now be satisfied with long polling between browser and OH2 since I’ve learned what long polling is. Seems to me that I now need to know if long polling is the default polling method for OH2 Things and Widgets.
I vaguely think that a next step is that I make some OH2 object rendered in the client browser to launch a server shell script on receipt of mouse clicks or some other user interaction. Of course, that object will need to be appropriately linked to the exec binding that I’ve installed. Along with the ability to launch a server script on command, I want its String to have a long-polling stream established so that its displayed text updates when the server answers the long-poll.
That is where I’m at, yes, having a “…very significant lack of knowledge of how OH works…”, still not able to see how to associate an Item object to a virtual (i.e., “NOT A PHYSICAL” [CORRECTION: Not capable of direct communication]) device. But I’m trying…
The key is that you are jumping over a middle step.
The binding communicates with your device.
The binding represents a device or API as a Thing (from here on only applies to 2.x version bindings).
Each piece of data or each actuator is represented as a Channel on a Thing.
Each Channel gets linked to an Item.
Everything else in OH works with Items, including the UIs, Rules, persistence, etc.
So what you need to focus on is finding a binding that can communicate with your device. From there you should use standard OH concepts like Items.
Now to your specific desire for long polling, that has to do with the OH REST API. You cannot use that to interact with your device. You need a binding for that. And to my knowledge, there is no binding that supports websockets or long polling.
This is why, when we interact with a DIY device, we program the device to push it’s data and/or receive commands directly using something standard like MQTT or programming the device to make REST API calls into OH too set the state on an Item.
Somehow I’m not understanding. The exec binding IS communicating with my device, at least as well as any binding can - via a script, because the device is USB-connected. The Arduino has no IP address of its own - it is script-controlled only. Are you saying that my server cannot serve as an intermediary or bridge device? If that is the case, did I overlook that being stated in the documentation?
What I’m saying is if you have the exec binding connected to your device, you need to link your Exec Thing Channels to Items and put the Items on your sitemap or HABPanel.
When you started taking about websockets and long polling streams I thought you wanted to talk to this device over a network.
There frequency of polling, how data is obtained, etc is all handled by the binding. All the UIs do is show the current state of Items and send commands to Items for actuators. You don’t need to care how the UIs do it because their polling is completely independent of the polling and event handling that gives Items their states.
I tried to avoid that misunderstanding in my OP when I said:
English comp was never a strength of mine. My apologies.
Nonetheless, at the risk of frustrating you, please let me continue to ask:
If you don’t mind, I want to be more explicit and slightly reword your statement by changing “Items” to “Item objects” to clarify to me that you mean the Item as created from its definition in the .items file and instantiated in server memory during OH2 runtime, not Item as being the physical device with its own OS. You might have already noticed that I’ve done that when I’ve referred to Things and Items. This point may be a small one to most people, but I, as a beginner, get confused reading the documentation if I don’t have it clarified…and the documentation emphatically does not clarify it sufficiently.
And here’s why I need it clarified: I see examples in the documentation of defining an Item by doing so with a text line in an .items config file. Fine, I could do that - for Item and Thing both. BUT, if that is the way to make an Item, that is only able to make an Item OBJECT as far as I’m concerned, and the documentation then becomes confusing when it seems to elsewhere make an Item appear instead as a physical device. Having no physical device in my system that is a clear candidate to be a physical Item, I want to know if I can make a virtual Item represented by an Item definition be an adequate Item, since that is the best that I seem to be able to do. I sure would like OH2 to work as a front-end for my system.
The convention I use on this forum, and others do as well, is to use “Item” with a capital “I” when referring to the OH concept and “item” with a lower case “i” when using the standard usage of the term. The same with Things and Channels.
This is usually referred to as the Device.
It would be helpful to point where you find that impression so we can fix the documentation.
Eclipse SmartHome strictly differentiates between the physical view and the functional view on the system. While the physical view is required for setup, configuration, troubleshooting, etc., the functional side covers the information that matter to applications, such as user interfaces and automation logic.
Things are the entities that can be physically added to a system and which can potentially provide many functionalities at once. It is important to note that things do not have to be devices, but they can also represent a web service or any other manageable source of information and functionality. Things provide their functionality through a set of Channels. Channels are “passive” and can be regarded as a declaration of a Thing, what it can offer. It is up to the individual setup, which of the Channels are actively used through Items (see below). [emphasis is mine]
Items represent (fine-grained) functionality that is used by applications - as user interfaces or automation logic. Items have a state and they can receive commands.
The glue between Things and Items are Links. Links are associations between exactly one Thing Channel and one Item. If a Channel is linked to an Item, it is “enabled”, which means that the functionality that the Item represents is handled through the given Channel.
So it explicitly states here that Things do not have to be connected to anything physical and it further states that Items get Linked to Thing’s Channels.
Items represent information or single control points to OH in a standard and abstract manner. You can have Items that are not linked to anything at all. You can have Items that act as a proxy to multiple other Items. You can have Items that are linked to Things that have no physical device like a weather service API.
Except for the links to a Thing’s Channel, the rest of OH does not need to know or care what, if anything an Item is linked to.
Amen, amen! I hope to wait to offer ideas until I’ve achieved a better understanding of OH2 capabilities and of the larger communications problem. For now, I’ll leave you with a drive-by: the word “view” in what you quoted above is less normal to me than a word such as “level”.
In the meantime, I just now found this forum posting which may be my salvation. Off to read it…
