Very nice Jürgen
very nice… good job 
This really looks better now from my point of view, still a bit missing.
Most important, your GUI version does not contain any information about installing a binding via GUI, so a new user will not find the VThing binding when creating a new thing.
Second, I would like to see this as a MainUI page, not a sitemap for BasicUI.
Anyway, good start
Not with the model, for now, but:
In the Category field of an Item, it is not obvious, that you actually have to type with the keyboard, where everything else is with the mouse. Initially I clicked desperately with the mouse into the field …
Either the Category selector should open with a mouse click or there should a hint “type here”.
For adding an Item, one assumes that one creates an Item from Setting-Items. This works, but then you’re stuck in a dead end, no way to link a Thing from there.
From Edit-Item there should be a way to link a Channel or a at least a hint that you’ve got to link from Thing. Or would a hyperlink to the Thing Channel editor be possible?
In the Channel View it is not obvious that above is the Channel and below a linked Item, maybe an edge between would help, or UML-like <stereotypes>:
1 Like
I might do that, creating a tutorial forces you to learn 
But my tutorials are not of much use if the vthing binding is not included in the addons, so I’d prepare a pull request first.
1 Like
I created [vthing] Initial Contribution by weberjn · Pull Request #10408 · openhab/openhab-addons · GitHub
First let me say its great that you are contributing and great to see you can create bindings and clear written instructions. Welcome to openHAB and dont let people get you down if they dont share your vision and please dont take offence on the following I write as I am busy and dont want to write a 3000 word essay so my short points are due to being busy and not trying to be rude…
- I tend to agree that using an existing binding like the network or astro is a better idea as there is a higher change the user can keep what they have built instead of deleting it at the end of your tutorial.
- I dont like the idea of pushing basicUI, it is probably going to get phased out and it is only there currently for backwards compatibility whilst the newer main UI gets finished.
- Did you know that a ‘color’ channel supports ON and OFF commands as well as HSB and PERCENT type commands? I would call it wrong to create two channels, one as state and the other as color unless there was a very good reason to do so. A single color channel still can be used to display the exact same controls that your after. Reason I would call it wrong to use multiple channels is that when Alexa or Google see the channel/item they will know how to control it and see it as a single light, your multiple channels will get seen as two globes. There is probably a way around this that I dont know, but the point is it is more complex when a simple solution is already able to be implemented.
- Please if contributing make sure you use ‘openHAB’ and not OpenHAB as the correct way is with lowercase o.
Matt, I am grateful for your feedback.
I wrote the Virtual Things addon to scratch an itch I had:
I was trying out and evaluating what the open source community has to offer for home automation.
If I evaluate a software, I like to install it on my machine and play with it. This should not take a lot of time or extra software or hardware.
FHEM has a First Steps Guide (using a Dummy Thing) that got me up and running quick. But in the end I did not like its Perl based architecture.
With openHAB I love that it is Java and OSGI based. But evaluating it is hard, and the website does not hint to the contrary (a system that needs an own Raspbian distribution must be hard, it seems. Actually, it is quite easy to get openHAB up and running.).
New users, people looking for new software, bloggers or journalist should get openHAB up and running, very quick, without the need for hardware things.
This is what I wrote my tutorial and the Virtual Thing it is based on.
ad a) network is hard to setup. Astro is great, but read only. I wanted something simple with quick feed back.
ad b) basicUI is supported by the Android app. And it is easy, if you have a programming background. (I actually believe low code is harder than programming, as low math is harder than knowing calculus, but opinions differ).
ad c) to learn and exercise an extra channel is better
ad d) OK.
Juergen
We all learn in different ways so more guides and help for users to learn the better and good to see your enthusiastic about openHAB…
BasicUI: as mentioned I see it as a dead end and not worth learning for a new user and I would not be surprised if it got removed in a few years time, it is only there to make the transition to V3 easier. Just my opinion… The whole reason for V3 was to remove the multiple UI’s that confused new users and to bring everything into 1 Main UI, so I feel it is going against the direction V3 is headed in.
Extra channel: Then why dont you rename the channel to ‘Sleep Mode’ or ‘Night Mode’ or some other function that allows a second switch to be used to give more examples, yet encourages people to learn that multiple controls can be linked back to a single color channel. Just my opinion that it is good to show users what is a common stumbling block and that is not knowing that you can setup a switch, a dimmer and a full colour control back to the one channel.
Good luck and this is only 1 opinion and I am sure others will disagree.
I’m a total newbie to openHAB and some virtual device tutorial was the first thing I looked for without success as of now.
I have been scanning through the existing documentation and tutorials and find them pretty opaque. This is mainly because they don’t relate to any device virtual or otherwise that I can replicate here. I already have a ton of home automation stuff cluttering my shelves so I’m not about to buy more.
I did find the Magic binding which seems to be designed for UI testing but I have not uncovered a tutorial using it yet. It seems like @weberjn work might be integrated into that effort?
Anyway a tutorial that I could implement directly and tinker with would have been a great help. I’m at a point where I’m not even sure I can formulate a useful question but I’m going to have to try or give up soon.
Anyway this is just an upvote to the idea of a tutorial using virtual devices.
Besides the add-ons listed in the oficial documentation, there is also a marketplace where you can find a “magic binding” whose purpose is the creation of virtual devices.
OP already found the magic binding but no tutorial using it.
AFAIK, there is no such.
yes I think I mentioned that binding.
I might try this out by creating a virtual building in my model to see if I can practice doing things. At the moment I’m trying to sort through a group of radiothermostats but I think I’d rather blow up some virtual ones first to see if I can sort out group commands and models etc.
If you open a new post and describe what you’ve looked at (so you don’t just get a RTFM reply) and what you don’t understand I and others will be happy to clear up any confusion or challenges you might have.
There are a number of bindings that do not require any hardware that can be used to get a feel for how OH works. Astro, weather bindings, HTTP (if you have an end point), MQTT, Exec … all of these are usable without having a physical device.
The key thing to understand with OH is there are two layers of abstraction. The first layer is the Things which is the layer of abstraction between the technology, devices, and APIs that OH can integrate with. The second layer is Items. Everything in OH except for Things operate on Items: rules, the UI, persistence, etc. It’s possible and reasonable to exercise and learn on OH with just the Items because whether a Switch Item is linked to a Hue light or a Zigbee light or even a Modbus light doesn’t matter. A Switch Item is a Switch Item and behaves the same not matter what.
For this all you need are Items. You can create Items that are not linked to any Thing and experiment as much as you need without risking the physical devices. Once you have worked out how it works and how you want it to work you just need to link those Items to the Things and nothing more. You don’t really need the Things to do this, you can do it all with the Items.
1 Like
Thanks Rich,
This topic is about something I think might help other newbies like me. A tutorial often has examples one can try variations of oneself and in this case virtual devices would be a huge enabler for that. So far any tutorial I have found only allow me to “look” not touch and more importantly twiddle.
I’m at the stage it’s hard to ask a useful question however I did post one in the beginners forum about configuring some thermostats. Conceptually openHAB makes a lot of sense to me so far but the mechanics of implementing the concepts are eluding me at the moment at least from the GUI side.
The thermostat post (I’ll see if I can post a link to it) for example speaks to the model. It seems like if I’m going to the trouble of creating a hierarchical model of my home then I ought to be able to leverage it like “turn on all the lights” or set all the thermostats to 10C. If I can’t then I may fall back to shell scripts and curl.
Perhaps if I can grok the magic bundle I can write such a tutorial myself before I forget how confused I am… TBD.
Meanwhile I think I’ll read that last paragraph over a few dozen times as I sense insight there.
Thx again
There are two ways to model a home automation (probably more but for now let’s just consider two). One can model it physically (e.g. this light is in this room on this floor of the building) or one can model it functionally (this Switch Item represents a light switch).
The semantic model covers the former. You are looking to do the latter. That’s going to require either creating a parallel functional model (e.g. create an AllLights Group:Switch Item and add all the light switches as members of the Group, commands sent to the Group are forwarded to all it’s members), or creating a rule that finds all the Items tagged with “Switch” and “Light” and commanding them one by one in a loop.
HABot, an NLP processor add-on to OH can sometimes handle a request like “turn off all the lights” but that more suitable for a free text type interface or voice interface than a control panel type interface.
Tutorials are always welcome but I think focusing on virtual Things is the wrong path. The whole point of OH is to normalize everything (i.e. Items) so the logic and UI doesn’t need to know or care about any of the specific technologies and APIs. Given that, you don’t need any Things at all to exercise just about everything OH has to offer in terms of UI, rules, data analysis, etc. Sending noobs down the path of creating virtual Things would be the wrong path to understand how OH works. That time is better spend understanding how Items work and interact with the rest of OH.
In short, virtual Things don’t add much to understanding OH. Focusing on them is largely a waste of time for new users. About all you’ll learn is:
- how to create a virtual Thing which isn’t going to be useful past the experimentation phase anyway
- how to link an Thing’s Channel to an Item, which isn’t that complicated in the first place and doesn’t really affect how an Item is used in the first place.
Thats interesting. I don’t think the focus is on virtual things at all.
The focus is on a tutorial that can be implemented with some interaction. In order to do that two disparate beings have to have the same resources. So one way to to that is to ensure the author of the tutorial is using the same devices and other resources as the student or consumer of the tutorial. One way to do that is to leverage virtual devices, at least if they are simulators and provide input and output.
An earlier comment you made was:
I find this difficult to believe. Can an item react to an input command or provide changing data back to whatever UI is running? If items can do this then I’ve really missed something.
Also I’m not concerned about blowing up a physical device really it’s more blowing up my model. The UI seems more fragile in 4.04 than in 3.4x to me and my model is not behaving well using Firefox on linux.
Maybe take this other topic to the thread on thermostats. I’m using the physical model at the moment not the functional model.
Yes, with some configuration.
There is a known issue with caching in Firefox. You need to do a forced reload on MainUI when making any change to the OH config or else the change doesn’t show up.
Already done. See my reply there.
OK thx I think I have the evil chrome here I’ll try that also.
Meanwhile I have been playing with magic::thermostat and created a Magic Mansion with a couple of rooms and thermostats. Of note was @rlkoshak question about which binding which becomes important to the rest of the model rather quickly… nudge.
I’m not sure Magic does exactly what was envisioned in the origins of this thread. TBD.
Many thanks again. Doing homework on this for a bit…
Pretty much any other browser that uses webkit will work. I like Brave and Opera., Or you can hit crtl-shift-r (IIRC) to force reload the page on firefox to pick up the changes.