Great, did not know that mappings in the labels are transformed correct for the UI.
But this does not bring as a step closer to solve your issue.
@ysc Any clue what the culprit could be or how to debug ?
Not all Groups are part of the model. In particular, if you have functional Groups, those are likely not going to be a part of the model. That’s not how the model is designed to work. The model is supposed to model the “real world” and as such a piece of equipment can’t physically be in two different locations at the same time. Of course, we all know that might not necessarily be true in the real world but, as with any model, certain constraints need to be applied.
So as a general rule of thumb, in the model, you wouldn’t model something like “All First Floor Lights” because the model already encodes that information. However, on your UI or in your Rules you might want to treat all the first floor lights as one. In that case you can still have the Group. It just won’t be a part of your model.
And that’s fine. Not everything has to be a part of the model.
Without a lot more specific details there’s really no way to tell whether this is the expected behavior or not. It doesn’t sound like expected behavior but there are a lot of variables. I recommend filing an issue on the openhab-webuis and gather all the information requested in the template.
One would ask why you have a large number of similar type rules instead of one generic rule that handles all of this in the first place. But in either case, it’s the same code whether it’s running from .rules files or when running in a Script Actions. If you can’t figure out the java.time stuff in the .rules files there should be no expectation that it’ll be any different in UI created script actions.
To more easily create rules through the UI, create the first one, click on the code tab, copy the YAML to the clipboard. Create the next rule, open the code tab, paste the previous rule and edit to make the new rule. Or stick to .rules file. You don’t have to move rules to the UI.
It’s not.
Just to be clear, what type of Item does the Thing Channel require? It will only list Items that are compatible with the Channel.
It’s strongly encouraged as there is a lot of functionality like automatically creating the overview pages require it. It’s also easier to create a bunch of Items from a Thing and stuff like that. But it is in no way required to build a model.
That should still work because sitemaps are still supported and sitemaps do it through the label. MainUI Pages use metadata.
They are, for items in .items files only, for “managed” items i.e. in the JSON DB they are not. State description options (the “mappings”) are defined I believe in that order:
- provided by the channel if applicable
- provided by the pattern or transformation between brackets at the end the label, for items defined in files
- in the “options” config parameter of the “stateDescription” metadata namespace (that you can set in files or the UI)
Apprently only those items “work” in the end, so this sounds like a bug.
3.0.0.RC1 UI
When adding Link to Item from Thing directly - create new Item, adding more than one cause first one to be overwritten.
When firsly adding 2 items in Item menu and then linking them with Thing channel - existing Item, it works
I thought that might be the issue at first, but it really doesn’t seem to matter whether it is a String or Switch Type Channel. It is always the same 10 Items that are displayed when I attempt to Link Existing Item, which is what I am struggling with. Why don’t the other 390 Items show up. For those Items that have a Link Button, I can reverse the process and effectively link the Item to a Thing/Channel even though the Item isn’t listed by the Channel when I attempt to Link Existing Item. Just very strange and unexpected behavior.
I have problems with the KEBA binding from openHAB 2.5.11 and also the openHAB 3.0 RC1. Both run in two separate virtual Ubuntu Server 20.04 LTS. openHAB 2.5.11 with Zulu JAVA 8 and openHAB 3.0 RC1 with Zulu JAVA 11. In openHAB 2.5.11 i tried like every time to define the binding with a .thing and a .item file from the documentation. In openHAB 3.0 RC1 i tried only to use the new UI for creating a thing and items. In comparison both show the KEBA Binding online, but both did not show any values. Numbers stay NULL, strings are empty, and so on. I searched the forum and found this and this. But openHAB 3.0 RC1 have no TCP-Binding, so the first solution could not work. The second did not help, because I did not found a newer KEBA Binding on GitHub then the from the openHAB 3.0 RC1.
The KeConnect P30 could also be used with Modbus, I saw the openHAB 3.0 RC1 Binding but did not understand one word in the documentation. Seems that Modbus is more something for programmers then endusers and not a solution for the KEBA Binding problem.
Would be fine if anybody who understand java programming and Binding development could have a look at the KEBA binding for the final openHAB 3.0 version.
Additional information: Just proved for myself that the P30 is working with a test installation of ioBroker on my Raspberry Pi. Only installed their KEBA adapter, put in the IP of the P30 and got the values. 
I found that to be rather annoying. I imported all my items in the UI and then had to remove the “[%s]” part from every item label and move it to the item’s metadata. For some 100 items …
Yannick, is it asked too much to still change that before release and create metadata instead ?
Else on release there might be many users to share my fate.
3 Likes
I’m sure Yannick is quite capable of deciding for himself if that’s a “missing feature” or a bug worth changing.
Merging PRs is always the decision of the repo maintainers.
Feature freeze this week is the general guidance to not risk anything so shortly before the release and rather keep features for an upcoming release - but maintainers can certainly do exceptions to this rule.
FTR, tomorrows snapshot will bring a couple of fixes wrt automation, see https://ci.openhab.org/job/openHAB-Core/620/changes.
1 Like
Yeah, really nice work on nailing some of those automation issues! Looking forward to that next snapshot.
you mean in the “add items from textual definition” screen?
yep
Well, I understand it would be practical but it’s certainly not a bug that the items were added the way they are defined. I’m a little lukewarm on adding some text-parsing behind-the-scenes black magic at the last minute, tbh.
I feel that sounds more like the job of a sed command or a text editor like vim.
A couple more observations as I am trying to learn and use the UI to construct rules. In the following test rule, only the first command (setting vFFmpegCamEnableMotion to OFF) is executed. The Dimmer command (setting vFFmpegMotionThreshold to 12) does not execute. Also, I see no postUpdate option in the rule UI. Is that by design or something that could be added in the future?
triggers:
- id: "1"
configuration:
cronExpression: 0/30 * * * * ? *
type: timer.GenericCronTrigger
conditions:
- inputs: {}
id: "3"
configuration:
itemName: AstroSunData_Rise_StartTime
state: now
operator: <
type: core.ItemStateCondition
actions:
- inputs: {}
id: "2"
configuration:
itemName: vFFmpegCamEnableMotion
command: OFF
type: core.ItemCommandAction
- id: "4"
configuration:
itemName: vFFmpegMotionThreshold
command: 12
type: core.ItemCommandAction
Nothing in the logs indicates any sort of error and I have full TRACE enabled
log file
2020-12-16 18:33:45.974 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'vFFmpegCamEnableMotion' received command ON
2020-12-16 18:33:45.975 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'vFFmpegCamEnableMotion' predicted to become ON
2020-12-16 18:33:45.975 [INFO ] [openhab.event.ItemStateEvent ] - Item 'vFFmpegCamEnableMotion' updated to ON
2020-12-16 18:33:45.976 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'vFFmpegCamEnableMotion' changed from OFF to ON
2020-12-16 18:33:49.449 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'vFFmpegCamEnableMotion' received command OFF
2020-12-16 18:33:49.451 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'vFFmpegCamEnableMotion' predicted to become OFF
2020-12-16 18:33:49.451 [INFO ] [openhab.event.ItemStateEvent ] - Item 'vFFmpegCamEnableMotion' updated to OFF
2020-12-16 18:33:49.452 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'vFFmpegCamEnableMotion' changed from ON to OFF
2020-12-16 18:33:49.456 [INFO ] [openhab.event.ItemStateEvent ] - Item 'vCamFFMpegAlarm' updated to OFF
Finally, I have a number of DSL rules that use Astro sunrise and sunset conditional comparisons with now() (ie now.isAfter(sunrise) type commands) that I carried over from OH2 and none of them work. I’m assuming this has something to do with move to from Joda to Java time, but I haven’t been successful in figuring the proper syntax to make such conditional comparisons work. Any help here would really be appreciated.
val day_start = new DateTime(AstroSunData_Rise_StartTime.state.toString)
val evening_start = new DateTime(AstroSunData_Set_StartTime.state.toString)
if (now.isAfter(day_start) && now.isBefore(evening_start))
There is an open Issue on that. I think it was just forgotten. But I think it needs to be added to core.
It’s not necessarily an error but I’m all but certain you can’t use DateTimes in Conditions like that. You’ll need to create a Script Condition and do it in code. “now” is always going to be > AstroSunData_Rise_StartTime.toString alphabetically which is what that condition does as written.
That explains why the rule is never running.
I think the following will work.
val day_start = AstroSunData_Rise_StartTime.state.toZonedDateTime
Maybe it’s getZonedDateTime. I’m on my phone and can’t look it up easily.
Hi @iLion
I’ve got the same issue (2.5.1 and 3.0) --> like shown in the thread I set up OH2 on a rasperry with UDP binding just for the Keba Connection. Using the Remote openHAB Binding I connected OH2 to OH3 --> working so far.
Regards,
Herbert
Thank you very much for your help and insight. I often rely on your posts for help.
It‘s true that the items were defined that way, but it‘s a way that worked in textual config and breaks in databases config. So either the data should be removed or better converted to the way it needs to be configured in the database.