To evaluate and test OpenHAB quickly there should be no need of actual smart home hardware.
I created a new binding for a Virtual Thing, a virtual lamp, that has three channels: on/off state, color and on time as string.
I’d like to have the Virtual Thing implementation code added to the OpenHAB addons.
A Virtual Thing makes it possible to write a quick OpenHAB Tryout Tutorial where you should get OpenHAB up and running, get feedback and play with the virtual lamp:
I plan to add another chapter with a rule and mqtt, e.g. flash a second lamp each full minute and notify an mqtt topic.
That I chose OpenHAB was not because I found it easy to understand, but for Java vs Perl and the vastly superior architectural base of OpenHAB and OSGI.
Of course, one can write an introductory guide with Virtual Things and the Gui, too.
I started with textual config because being a server side programmer I find the textual config and rules far easier to understand than the gui based configuration and the model. Also, I find it easier to follow a tutorial where you copy and edit config files than to follow videos where you have to rewind several times to actually see where you should click.
When I learn I need to learn by doing, so to get to understand OpenHAB I tried to implement a dummy thing for OpenHAB, and enjoyed programming with Java, Javascript and Websockets.
For most people, I think this would address your original statement.
Don’t get me wrong, I appreciate your willingness to contribute, but it would be better to first look for how the community has addressed this before declaring that you have the solution.
As for your code, I don’t think it’s a terrible idea, but I’m not convinced its necessary. Virtual items are already possible in openHAB (they just don’t have any channels). And more often than not, people who find openHAB already have hardware that can be controlled by it. If they don’t, it’s easy for most to pick up an inexpensive WiFi outlet. For someone new to home automation, the real magic is when you press a switch on your computer and an actual, physical device toggles on or off.
I’d encourage you to take a look at the demo and revive the thread if you have ideas. Your perspective as a new user is valuable. If you weren’t aware of the demo, maybe we need to do more to promote it.
While text-based configuration is still viable, a lot of effort is going into a GUI that can serve both programmers and non-programmers. As you’re likely aware, it’s not easy to develop any interface that can satisfy both new and advanced users, and many of us are still figuring it out as we move from OH2 to OH3.
I’m not going to tell you that you should use the GUI (I’m only using parts of it), but the ideal is for new users to start with the GUI and then grow into the system. So, efforts need to go toward improving the GUI, not pushing users away from it just three months after its release.
If a system is better defined with gui or with code is hot debate. Even Microsoft Windows got Powershell for pros.
Best if you have both, gui and text.
But my point is not gui versus text. It is the need of a simple Virtual Thing.
I want to play with a system on my machine, without the need for special hardware. Not even an SD card. Just unzip. Quick, easy and with an simple tutorial, as FHEM has.
I want to play with, evaluate and feel OpenHAB, FHEM, Wildfly, Grafana, Docker or TensorFlow on my machine. Not in somebody else’s cloud.
As for the demo, it is a great demo for what OpenHAB can do, but not for how you make it do.
In principle you’d need a menu of 50 images of the features of the demo that link to videos explaining how to make the feature work.
I don’t think it’s a debate at all. It’s just a challenge with anything (software or otherwise) that’s trying to serve a broad user base with differing needs. The debate only occurs when people present their worldview as the only one that matters. And to be clear, I’m not accusing you of doing that.
Moreover, the Getting Started documentation speaks pretty extensively to UI versus code.
Personally, what I’d like is if openHAB had a super-basic mode for beginners without programming experience. Of course, it’s easy to say that, and hard to determine what should actually go into it (particularly with open-source software that’s in constant development). Really though, the goal would be to help users understand that things get harder when they move to intermediate and advanced tasks. For example, I really don’t think it’s a good idea for new users to try to learn openHAB and MQTT at the same time. That’s really difficult.
I think you’ve built something that works for your particular needs, and that’s great. But you suggested that everyone needs your virtual thing just to get started, and now you’re mentioning Docker, Grafana, and TenserFlow. So I’m unclear on who you’re trying to serve.
I’d personally rather see you contribute to the existing documentation so that it benefits from your perspective. But at the very least, I’d suggest that you change the title of your tutorial from “The openHAB Tryout Tutorial” to “An openHAB Tryout Tutorial” to avoid confusion.
And if you want to pursue this, it would be best to do so in GitHub, where you can discuss it with developers. I can say whatever I think, but I’m not making any decisions on what goes into the system.
There is the Network binding and Astro Binding which do not require any everywhere hardware or any extremal dependencies. There are many bindings like the weather related bindings that only require an account.
I don’t have a strong opinion on this particular binding. But it doesn’t feel necessary. You can exercise pretty much every part of openHAB except for Thing creation/discovery already. Something like this I think we’ll serve to obscure the fact that Items can exist without Things which is a prolblem some have already.
I agree though that if this is intended for new users, a UI be first example is required. The text can be presented too, but by the time must users are knowledgeable enough to create text configs they probably don’t need a binding like this anymore anyway.
But, as Russ hints at, anything you get here is going to be the opinions of what amounts to openHAB’s help desk. We are not the developers and maintainers of the code, who will have their own opinions.
I think a system like OpenHAB or FHEM is rather used by people with a programming or advanced user background, like people who buy a Raspberry Pi.
Computer users who are not fond of tinkering would rather buy a commercial central in a nice white plastic box or subscribe to a commerical web service.
But even for people with a computing background the start should be way easier.
OpenHAB’s web page has a nice red Get Started button. If you follow it, how many pages do you need to read and how much time does it take to get something working?
How many minutes do you need for my guide and have a positive experience?
I do think that the start to OpenHAB should be easier. That’s why I think a Virtual Thing like a virtual lamp is necessary and I wrote the tutorial.
A system is best learned in lab sessions. Learn a topic, try out, rejoice.
Astro is great. And a good start to play. But it is oneway only, data flows out from Astro. To have something to play a new user needs something that gives feedback.
MQTT also gives feedback to a listening mosquitto_sub, but I wanted something more visual.
This is a complete false assumption. If you read the many post from new users, you shurely find out, that many of them have none of these backgrounds and ask for simple gui solutions.
We have put a lot of effort into this to give new users an easier entry point.
I don’t have a programming or advanced user background. Pretty much everything I’ve learned about Linux and my Raspberry Pi came this community and the Internet, and almost all of that was within the two years that I’ve been using openHAB.
I’d recommend spending some more time in our community talking to others. I hope you’ll stick around and become a valuable contributor, but I think it’s fair to say that you could learn more about us before telling us who we are and how we should do things.
Andrew,
I actually was trying to do a gui version of the tutorial today.
I find it rather difficult to get something done with gui and am still stuck in the model/location/equipment/point maze.
Textual Things-Items-Sitemap looks easy and straightforward for me, but not the model Thing linkage.
But I’ll continue trying. To learn was the reason I wrote the binding.
ahhh… yeah, that is the new method of modelling your smart home in OH3 and you are not the only one a little befuddled by it. (me raising hand) I’m not sure figuring it out is important for your use case (as far as documenting your virtual Thing binding) and maybe skip ahead and just discover your Thing thru the interface, create some items from the UI and maybe create a OH3 page with your items, get the UI to switch, dim and change colors
The Model is abstract, hopefully it will help folks model a bunch of devices (they already own) in a logical way and it practically creates an interface for you.
Understanding exactly what you don’t understand or are having trouble with in the model will help us improve the getting started docs and perhaps guide us when someone (probably me) gets around to writing a reference page for modeling in the docs.
But as has been mentioned, the model is option. If you don’t want it you don’t have to use it.
The biggest confusion I’ve seen is assuming that the model it flexible enough to model things from a functional perspective. As with many ontologies, it’s not flexible enough to do both. It really only supports modeling the physical layout of your home automation. You can’t have the same piece of equipment in two locations at the same time, for example.
The second biggest confusion I’ve seen is the assumption that everything must be in the model. Based on my own setup, I’d say only about 60% of one’s Items should actually be in the model.
