Now that I’m able to use Habmin and the new Zwave plugin (and create items from there) I came across a few things that I felt could be a bit better and have a few questions as well. Some of these may be on deck already so I didn’t want to just go and create a bunch of issues on Github. It should also give a “new user” perspective, as I’m pretty new at OpenHAB (but I’m a web dev so I do have a technical background).
Thing configuration
Show the node # somewhere other than just the label. I went and relabelled mine because I have a lot of the same device and it’s hard to keep track. However, then I lost the Node #, and there’s nowhere to really pull that info up from the UI.
Simple way to “test” channels. I.e. When I was setting up my dimmers/switches/outlets, it would’ve been super handy to be able to quick test a command from the interface so I can see which one I’m working with (i.e. “is node 8 the sink switch or living room…”). Otherwise I had to create the item/channel link, reload my sitemap, and test.
A bit more info on the channels. I.e. for the Astro binding, all I see is a set of “start time”, “end time”, “duration” channels, but no easy way of knowing if they’re sun rise, sun set, etc.
Items
Ability to add groups?
Ability to add “pseudo” items (i.e. for Dimmer things, you can also associate a Switch item that uses the BASIC command…much easier than using a slider to turn it on/off)
Rules
I kept getting an error when trying to create a rule. (something about missing root block)
Is the purpose of “source” to be able to just directly code the rule/when/then blocks? (If not, that would be super handy)…I tried using it but ran into the same issue as #1
Unfortunately, the ‘node number’ isn’t an attribute of an ESH thing… Currently, HABmin is targetted toward openHAB in general, so I’ve (so far) tried to avoid any binding specific extensions. This will change as I am adding more support for Z-Wave so will take a look at this, but it needs to be done in a way that doesn’t cause problems for things from other bindings.
Did you try the ‘home’ sitemap? This is autogenerated, so as soon as you add a thing, you can test it (I know the sitemap is a bit buggy at the moment though). However, I’ve also thought about adding something directly into the channel configuration area as well…
Well HABmin provides the facilities to do this, but the binding needs to provide the information. HABmin will print a one line description under the channel, and if it’s longer than 1 line it puts a button on the end which pops up a box with more detailed information. However, I don’t think I can come up with the information on every channel - that’s gotta come from the binding (and this is why the Z-Wave database has a number of fields for data entry - so it can be nicely presented. It still needs people to add it though).
Agreed - the items editor needs to be added yet. At the moment, it just displays items…
I’m not sure I understand this. I also suspect you’re talking about ZWave devices as you mention the BASIC (which I assume means BASIC command class?). I want to avoid making the UI Z-Wave centric. Any Z-Wave specific functionality (or other bindings for that matter) needs to be kept clearly separated to avoid screwing up support for the majority of other bindings.
I’ve not looked at rules for a while - it likely needs some work…
Yes, but it’s not implemented in HABmin2 at the moment. I could add it back relatively easily (it was used in OH1, but I was initially trying to stick to standard REST interfaces in HABmin2, so didn’t port this over).
I did try it and it certainly wasn’t working at the time. But yes, even with that, you end up doing a lot of navigating back and forth just to figure out items. Something inline would be way more useful in my opinion.
Using my example of the Astro stuff again: in the PaperUI, it shows something like this: astro:sun:f7ae7131:rise#start when I’m looking at the channel config (for each channel). It also has each set grouped (there’s a bunch of range sets each with start/end/duration). Habmin just has each item listed with the descriptive text. At least with the actually channel param there I can see the difference between each set (i.e. rise/set/noon/night/etc).
Actually, now that I think of this, it may be a database/binding issue. The Zwave dimmers I use have the channel for brightness, but should also be able to act as an ON/OFF switch (so perhaps they just need a channel for that).
However, I also meant the idea of creating items that don’t necessarily have a thing/channel to associate with (i.e. with my Ecobee I had created a DateTime item of Last_Occupancy_Time)
Ok - I’ll take a look at this. I think I misunderstood what you meant…
No - please don’t add a channel. You just need to change the sitemap if you want an On/Off button - just add a switch. The binding will support either dimmer commands, or ON/OFF commands for a dimmer channel.
At the end of the day, this is still a channel, and you link an item to it. The fact that it’s not physical doesn’t change anything. So, this needs to be implemented in the binding and isn’t anything to do with the user interface.
Is there a way to have both though (as in two separate items)? That’s what I had when using the 1.9 version of the binding and an items file. Having separate items also gives a bit more flexibility in rules. Or maybe I just need to define another item on the channel with the Switch type?
I don’t think I was clear enough in my example. It’s not something the Ecobee technically supports, but a separate item that uses a rule to simulate it (so essentially it’s like a variable that I can use on the sitemap, for other rules, etc). I found it here: Ecobee Examples · openhab/openhab1-addons Wiki · GitHub (see the rule at the bottom of the page)
So I tried that. It kind of works: on my sitemap, if I click the switch item, it will turn on the lights, but the switch toggle flips back to the OFF position.
As it currently stands, yes, I suspect you might need to do this if you want to have a single switch. I had a discussion about how this is managed on ESH some time ago as it drove the way I implemented the Z-Wave binding, and as PaperUI was implementing all possible types (eg for a COLOR, that is a color slider, a dimmer, and a switch) that are derived from an item, I had to do the same. I think the new sitemap definitions will allow the option to be selective.
Ok - so you mean an item that isn’t attached to any binding and is updated only in a rule? Again, this is something that should be possible simply by creating an item - as far as HABmin goes, as with the groups, I need to implement the item editor and then this will be possible (I hope I understand now ).
- that’s gotta come from the binding (and this is why the Z-Wave database has a number of fields for data entry - so it can be nicely presented. It still needs people to add it though).