@Bruce_Osborne: thanks for your advice and for sharing your experience. I guess I have to stick to openhab.
The overall concept is great in my opinion and to me it “feels” like the whole approach is right - this is actually why I am so surprised on how bad some details are.
I will try for another round or two.
Are there any configuration examples you could share that are not working as intended?
@rlkoshak: thanks for this information - If the item file really does no longer work/is no longer being intepreted, I am going to either maintain the item tags for the hue bridge service either in the JSON database by hand or revert back to the API, which offers a way to edit the item tags.
Kind regards,
Sure. Here we go:
Contents of file \192.168.178.30\openHAB2-conf\items\ABCD.items
/************************************************** Items ********************************************/
//—> EG
//–> Wohnzimmer
Switch WoZiTV “Wohnzimmer TV Anlage” [ “Switchable” ] {channel=“avmfritz:FRITZ_DECT_200:3e2fc4ba:087610278325:outlet”}
I have also tried this entry:
Switch WoZiTV “Wohnzimmer TV Anlage” [ “Lighting” ] {channel=“avmfritz:FRITZ_DECT_200:3e2fc4ba:087610278325:outlet”}
this file never seemed to be recognized or even read. I had the rest set up through the paper UI.
the channel info i copied from the Fritz!Dect 200 device channel - as far as I have understood the documentation and the forum, this is how it is meant to be.
The items file concent dates back from OHv1
In your conf/items folder create an *.items file
This is the beginning of my lights.items file:
// *********************************************
// ** LIGHTS **
// *********************************************
Group Lights (House)
Group MLights (House) //Lights for Super Lighting Rules
Group MaghribLights (Lights)
Group SunsetLights (Lights)
Group:Dimmer TVLights (Lights)
Switch LivingRoom_WallLights "Wall Lights" <light> (LivingRoom, MaghribLights, SunsetLights, Lights, MQTTv2) [ "Lighting" ] { channel="mqtt:topic:LivingRoomWallLights:OnOff" }
Switch LivingRoom_CeilingLight "Ceiling Light" <light> (LivingRoom, MLights, MaghribLights, SunsetLights, Lights, MQTTv2) [ "Lighting" ] { channel="mqtt:topic:LivingRoomCeilingLight:OnOff" }
It shows labels, groups, tags, bindings, icons…
The configuration of items files is detailed there:
Without further details it’s hard to guess. The first thing to check is that the openhab user has read permissions on the .items files (any file in /etc/openhab2 really). The second thing to check is openhab.log for any errors. There could be a syntax error in your .items file that is preventing it from loading.
The loading of .items files is one of those things that hasn’t really been touched in years so I doubt you’ve uncovered a bug or instability there, but that’s always a possibility.
Because all you have to to is save the file. That’s it. It will get picked up by OH, and if there are no errors in the file, loaded and your Items will be created in memory.
There isn’t anything you need to do. If you save a .items file in /etc/openhab2/items, the openhab user has permission to read that file, and the file has no major syntax errors, that is sufficient.
I’m sorry you find it really hard to believe. But unlike many open source projects, openHAB is 100% volunteer driven. And it’s an old project with a lot of history.
The volunteer(s) who created PaperUI and contributed it to openHAB (Eclipse Smarthome really) built PaperUI using a framework that none of the other maintainers know or have a desire to learn how to work in. And that developer abandoned the project. So now we are stuck with a UI that we can barely keep running let alone add features to.
But there is work ongoing to replace PaperUI (and several of the other UIs as well) for openHAB 3. In the mean time, PaperUI is all we got, as incomplete and broken as it may be.
Start small. “Just want to control Fritz switches with Harmony though Hue Emulation” is almost an end to end project utilizing everything that OH has to offer short of persistence. This isn’t really something you can pick up and get working in a couple of hours. So rather than approach it as an end-to-end all at once, break it into smaller pieces and get them working first. Build up gradually like Vincent suggests.
Pretty much everyone on this thread is actively using .items files and have been doing so for years (largely because of the PaperUI issues you site). And we haven’t experienced nor seen reported of any problems like this.
What’s in your logs? What is the permissions on the file?
It’s helpful to post code like this using How to use code fences, especially for dealing with syntax errors like these. The forum likes to make everything pretty which can mangle the code. In this case, your quotes should be "Switchable" but they are showing as “Switchable” (see the difference?). The latter version cannot be parsed.
If there is a syntax error, you will see it listed in openhab.log with the line and column number of the source of the error.
It is, see this link. As others already responded, there might be syntax errors or wrong permissions in effect to prevent success, but files are (re-)read.
Use openhab-cli reset-ownership and read the Logging section how to enable (more) debugging.
For some Admin I also have HABmin. For day-to-day there is Basic UI and, if you wish, HABPanel.
Thanks you very much, @vzorglub, this helped a lot - now I can change the .items file and it is being recognized in my openhab installation.
Thank you so much - it is working now - the .items file example from above helped a lot.
I also struggle with what’s the best thing for me. I understand some of the coding and making some rules and items.
I’ve got +/-30 items mostly z-wave actors running and things work and are stable.
What I find confusing is all the different ways you can reach a goal. I understand now the PaperUi is an extra feature designed later to make things easier. So is it also possible to run Openhab without using the PaperUi or any other Ui and configure thing only with .items and .rules etc? Would that be a better way so everything is not getting messed up.
I try now to just create a rule to make a light go on and off when my fibaro motion sensor sees movement and I just cannot get the job done.
The only reason I stick with Openhab and say to myself to try harder is that Openhab has the best Z-wave range I’ve ever seen. I don’t know why but it seems with Openhab every Z-wave actor has a better reach than when I used HA or Domoticz.
Anyway
I keep on trying, reading and learning
I am not sure how Thing Discovery would work without a UI. I use the recommended HABmin to discover Z-Wave things and then use text Items, rules, automations, etc.
My current recommendation remains unchanged:
Use PaperUI for Things creation and management. Take advantage of automatic discovery of Things where possible.
Use .items files to create and manage your Items. This is a soft recommendation, meaning it’s really not that big of a deal either way, but adding tags and metadata to Items is much easier in .items files right now. You cannot create Items that use OH 1.x version bindings in PaperUI, so using .items files guarantees consistency. Personally, I plan on migrating all my Items out of .items files as soon as we get some better support for metadata in the REST API.
Do not use Simple Mode. If you have it enabled right now, turn it off.
If you are an experienced developer, use Scripted Automation with the Helper Libraries. The Python libraries are the most mature but there is a lot of work going on for JavaScript too. If you are not a programmer, use the Rules DSL (i.e. .rules files). If your Rules needs are very simple, you can try the Next Gen Rules Engine and create very simple Rules in PaperUI, but beware that the docs and support for those are limited right now. In the future (beyond OH 3), Rules DSL will become deprecated.
Use HABPanel to create your day-to-day UI if you want more full control over how it looks and to support stuff outside of the standard. Use .sitemaps in all other cases. NOTE: in the past year the Android App has added HABPanel support. I don’t know about the iOS app.
Getting messed up how? I can’t possibly answer that without knowing what is “getting messed up.”
When you’ve tried and get stuck, create a new post, post the code you’ve tried, and ask for help. We are more than happy to help when you’ve shown some initiative to attempt to code it yourself. Also, be sure to look at the Design Pattern postings. There are lots of examples there. In this particular case, [Deprecated] Design Pattern: Motion Sensor Timer is a direct example of what you are trying to do.
That’s how i do it. Everything (including things) is done via files, my jsondb is completely empty. But i do not use zwave.
The only tasks i use PaperUI for is installing or uninstalling because these are one off tasks.
I have multiple instances of every thing:
Using files makes handling that stuff so much easier.
This is one of the biggest sources of problems that new folks encounter.
It is a little bit of a problem because it would be nice to streamline things for new people but the user interfaces are all things that were contributed by people and no one wants to throw away someone else’s hard work. As Rich stated, this whole application is written and maintained by volunteers .
As stated, Paper UI was basically never even fully finished and is not useful as a ‘user interface’ per se but… it provides a automated way of creating ‘things’. It also provides a quick easy way to configure your new thing and make sure it is online. As also stated things can be created manually with files but it is not a simple thing a new guy could do without much heartache and nashing of teeth ect.
Item file syntax is much easier to master, even for a noob and allows better control.
I would suggest to combine your rules and Fibaro motion sensor parameters. If you want to switch on/off any time without consideration time, light etc you do not need rules at all. Zwave devices are able to control direct each other. In my case eaxample parameter 6 is at 240 sec. It means in case of FIbaro sensor, that it sends motion signal, than it switch off after 240 sec, but if it senses motion, this timer restarts in the device itself:
I tend to agree to some extent with the OP. I’m only starting with openHAB and yes, it is rather complex/intimidating.
This project reminds me of XBMC many years ago, when the developers started with the original Microsoft X-Box … it was a bit ‘painful’ to get it to work. Fast forward 15 years later, and today we have OSMC, which runs on multiple platforms, including the Raspberry Pi.
Not sure If l am willing to wait 15 years. This home automation ‘business’ is very cut-throat and many players (component manufacturers) are engaged, and each with their own devices and protocols. Difficult to know for sure who will succeed and who will go bankrupt. Ideally we should end up with few communication protocols only, but that would require the multiple OEMs to agree on standards … unlikely this will happen any time soon. Lastly, to many on this forum, this is a hobby for now, and like all hobbies, you can spend 30 mins a day, or your entire weekends on it. Good luck to those assuming the journey.
That is the whole point of openHAB, to bring all these different systems together.
I sympathise with the poster Johann Dornbach. Openhab is not easy. BUT ! it IS rewarding.
Well, I have been struggling for three months now just getting going. Simple Home set up of around 30 items and presently stuck at getting Openhab2 to turn HUGE incoming JSON messages from Snips.ai; in to MQTT commands in Openhab. I just want to turn on lights etc, using a PRIVATE (non-cloud) voice control. RULES are hard !
I am not a ‘programmer’ of any sort and, at 63 years old, I find it difficult, but I am getting there. Excited to learn all the time.
I absolutely rely on examples and Documentation posted by ALL others, and particularly thank [David_Graeff] [Maintainer] for his outstanding work.
Openhab IS the way forward for me, and all others who value Privacy in Home Automation. and I thank all concerned for supporting it.
IF there was a way to encourage maintainers through ‘donating’ to the Project; I would give generously.
Openhab2 (or even 3 when it arrives) is definitely worthwhile learning Openhab, and progressing it in this modern age of money-grabbing , Privacy invading, Data collecting, rotten Corporations. There are precious few alternatives.
Thank you all.
Sure there is:
