This topic can be used to discuss problems/experiences/questions on the openHAB 3.0 Milestone 4 - see details at https://github.com/openhab/openhab-distro/releases/tag/3.0.0.M4
Still get this error:
E: Encountered a section with no Package: header
E: Problem with MergeList /var/lib/apt/lists/openhab.jfrog.io_openhab_openhab-linuxpkg_dists_testing_main_binary-i386_Packages
As usual here are the changes on the UI. There’s only one major change actually this week: you can now customize the cards shown the home page and generated from the model - look for the pencil button in the upper-right corner:
In this new editor you can restrict which tabs will be displayed, and choose whether non-admins or anonymous guests will see them or not, in case you don’t want them tampering with your system. Usual disclaimer that it’s not a real security measure, but it can be enough to hide unwanted UI to non-technical users.
You can also reorder cards, hide them if you don’t need them, change their title, background color or even put a background image to get something nice:
You may also insert separators between the cards to build groups:
As you may have noticed there are little badges in the location cards as well to provide some information at a glance - the good news is that you might see them without doing anything! This is another benefit of building your model correctly 
The way information is collected is detailed here and will surely end up in the documentation as well: https://github.com/openhab/openhab-webui/issues/556
Note that in most cases it will prioritize the points directly related to the location, and will only look for indirect points through the location’s equipment if there’s none. That way, you can exclude for instance some temperature measurements that shouldn’t be considered in the computed average for the room. Add only those you want to the Location group to relate them to the room directly.
It will probably not satisfy everyone and incomplete to some, but I hope it will probably be useful to most, in any case you can disable them or show only those you want by configuring the card. And it’s not set in stone, there could be improvements over time.
Due to lack of inspiration and time, the Equipment and Properties cards don’t have badges yet, but they’ll probably come eventually. But until then, there’s a way to customize the header of the card completely! You can edit their YAML code and add either a header slot (to replace the entire header with your components) or the glance slot to keep the title and subtitle and add your widgets underneath.
Here are some examples:
Temperature:
- component: oh-property-card
config:
title: Temperatures
subtitle: "Setpoint: 22 °C"
slots:
glance:
- component: oh-link
config:
text: "='Ground Floor: ' + items.ZW074Sensor_Temperature.state"
iconF7: thermometer
iconColor: white
color: white
style:
font-size: 12px
margin-top: 8px
- component: oh-link
config:
text: "='First Floor: ' + items.FGMS001Sensor_Temperature.state"
iconF7: thermometer
iconColor: white
color: white
style:
font-size: 12px
margin-top: 3px
- component: oh-link
config:
text: "='Outside: ' + items.FGDW002WindowSensor_Temperature.state"
iconF7: thermometer
iconColor: white
color: white
style:
fontSize: 12px
margin-top: 3px
Humidity:
- component: oh-property-card
config: {}
slots:
header:
- component: oh-gauge
config:
labelText: Humidity (Avg)
item: ZW074Sensor_Humidity
size: 250
value: 60
type: semicircle
borderColor: white
borderBgColor: rgba(255,255,255,0.4)
valueTextColor: white
labelTextColor: white
borderWidth: 20
style:
margin-left: 30px
SoundVolume:
- component: oh-property-card
config:
backgroundColor: black
slots:
header:
- component: f7-link
config:
text: Multiroom Audio Volume
style:
text-transform: uppercase
font-size: 14px
color: white
- component: f7-block
config:
title: Multiroom Audio Volume
style:
color: white
display: flex
flex-direction: row
width: 320px
justify-content: space-around
slots:
default:
- component: oh-knob
config:
item: MusicCast_Salon_Volume
size: 75
max: 110
primaryColor: white
secondaryColor: gray
textColor: white
class:
- card-prevent-open
- component: oh-knob
config:
item: MusicCast_Chambre_Volume
size: 75
max: 50
primaryColor: white
secondaryColor: gray
textColor: white
class:
- card-prevent-open
- component: oh-knob
config:
item: MusicCast_Bureau_Volume
size: 75
max: 30
primaryColor: white
secondaryColor: gray
textColor: white
class:
- card-prevent-open
Note the card-prevent-open class applied to interactive oh-knobs in the examples to prevent the card from being expanded when you click or tap these controls.
You can create the card by configuring it first in the Design tab, and then you’ll see it in the Code tab. Remember the keyboard shortcuts Ctrl-R and Ctrl-S to quickly switch to a preview and save.
Have fun!
15 Likes
Since OH3M2 i get this error
There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
and here is my rule
rule "set string_group_house_switch_light" when
Member of group_house_switch_light changed or Item switch_systeminit changed from OFF to ON
then
try{
var Integer local_integer_countnull = group_house_switch_light.members.filter[m|m.state == NULL].size
var Integer local_integer_countundef = group_house_switch_light.members.filter[m|m.state == UNDEF].size
if (local_integer_countundef == 0 && local_integer_countnull == 0)
{
var Integer local_integer_countoff = group_house_switch_light.members.filter[m|m.state == OFF].size
var Integer local_integer_counton = group_house_switch_light.members.filter[m|m.state == ON].size // maybe var Int instead of var Integer?
var Integer local_integer_countsum = group_house_switch_light.members.filter[m|true].size
var local_string_memberson = local_integer_counton.toString + " Licht(er) von " + local_integer_countsum.toString + " eingeschaltet"
var local_string_membersoff = local_integer_countoff.toString + " Licht(er) von " + local_integer_countsum.toString + " ausgeschaltet"
string_group_house_switch_light.postUpdate(local_string_memberson)
logInfo("set string_group_house_switch_light on", local_string_memberson)
logInfo("set string_group_house_switch_light off", local_string_membersoff)
}
}
catch(Throwable T) {
logError("Error", "Some bad stuff happened in \"set string_group_house_switch_light\": " + T.toString)
string_group_house_switch_light.postUpdate("Lichter Übersicht")
}
finally {
}
end
rule "set string_group_house_doorwindow" when
Member of group_house_doorwindow received update or Item switch_systeminit received update
then
try{
var Integer local_integer_countnull = group_house_doorwindow.members.filter[m|m.state == NULL].size
var Integer local_integer_countundef = group_house_doorwindow.members.filter[m|m.state == UNDEF].size // maybe var Int instead of var Integer?
if (local_integer_countnull == 0 && local_integer_countundef == 0)
{
var Integer local_integer_countoff = group_house_doorwindow.members.filter[m|m.state == OFF].size
var Integer local_integer_counton = group_house_doorwindow.members.filter[m|m.state == ON].size // maybe var Int instead of var Integer?
var Integer local_integer_countsum = group_house_doorwindow.members.filter[m|true].size
var local_string_memberson = local_integer_counton.toString + " Fenster/Türen von " + local_integer_countsum.toString + " geöffnet"
var local_string_membersoff = local_integer_countoff.toString + " Fenster/Türen von " + local_integer_countsum.toString + " geschlossen"
string_group_house_doorwindow.postUpdate(local_string_memberson)
logInfo("set string_group_house_doorwindow on", local_string_memberson)
logInfo("set string_group_house_doorwindow off", local_string_membersoff)
}
}
catch(Throwable T) {
logError("Error", "Some bad stuff happened in \"set string_group_house_doorwindow\": " + T.toString)
string_group_house_doorwindow.postUpdate("Fenster/Türen Übersicht")
}
finally {
}
end
Fixed!
1 Like
With the new DSL changes in OH3, it’s been hard to try to figure out what rule has failed and why. For example, I have a large number of rules for my lutron. I get an error like “Failed to execute rule ‘lutron-32’ with status ‘RUNNING’” and “Script execution of rule with UID ‘lutron-28’ failed: An error occurred during the script execution: Could not invoke method: org.openhab.core.model.script.lib.NumberExtensions.operator_lessThan(java.lang.Number,java.lang.Number) on instance: null in lutron”. It’s really hard for me to figure out which rule lutron-32 and lutron-28 are. In the past I feel like the rule name used to show up. Is there any way the rule name can be displayed to help track down which rule is failing?
Rules seem totally busted with M4 and don’t queue properly with loads of errors such as:
2020-11-29 20:43:06.865 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule ‘cdf8ab1ce1' with status 'RUNNING'
2020-11-29 20:44:06.750 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule ‘cdf8ab1ce1' with status 'RUNNING'
2020-11-29 20:44:06.754 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule ‘cdf8ab1ce1' with status 'RUNNING'
2020-11-29 20:44:41.293 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule ‘389dc4a8f8' with status 'RUNNING'
Trying to turn on all upstairs lights now just turns one on. @Kai is this related to the core change to use a threadpool for the rules?
Not sure if I got this PR right
Does this mean that it is no longer possible to access Things from rules?
you have restarted once or twice since install right?
Does the system settle down after a few minutes
What hardware is your install running on please
I just filed the following issue, as my textual rules ar no longer showing up and I see the provided error in my logs. Error still exists if no .rules file is provided.
Yes I’ve restarted a couple of times, I’ve swapped back to using the snapshot version I was using before trying M4 and those errors have gone.
With M4 any rules with multiple triggers seem to discard a trigger if the rule is already running. Prior to M4 the triggers would be queued up.
I believe that is only accessing via the REST API. If your rules hit the REST API then yes. If you are using something else you should be ok.
For all the rules posts, can you run “top” and see if your java process is running really high? Do you notice that your event bus is really laggy on actually updating?
1 Like
Same here. Problem with MergeList…
Latest Ubuntu Desktop
I wouldn’t say it’s really laggy, but it seems slower than 2.5. For example using hue emulation with Alexa, Alexa often complains that my lights are not responding, which happens when the item’s state doesn’t update quickly enough to keep Alexa happy. This happens a lot more with 3.0 compared with 2.5.
CPU usage doesn’t go above 12%
1 Like
Go to rules in MainUI and search for a substring of the rule name, it’ll list all to match, then spot yuor specific number
(@ysc Indeed it would help if the search included the -nnn strings so one could enter that directly)
Mea cupla - I have created a fix, so I’d suggest to move to the next snapshot instead, if this problem is permanent.
Trying to turn on all upstairs lights now just turns one on. @Kai is this related to the core change to use a threadpool for the rules?
Yes, it seems to be related to that, but actually the change now only provoked to bring this behavior to the surface as it existed before: The rule engine does not permit starting a rule that is already running. My assumption is that before the rules were triggered so quickly that the rule engine actually didn’t notice that they were running in parallel. Logging an error and not doing anything is probably the worst thing to do - let’s discuss on Rules fail to run with multiple triggers · Issue #1868 · openhab/openhab-core · GitHub how to best proceed.
FTR, the issue where @morph166955’s problem is analyzed is [OH3] 3.0.0M3 has substantial lag in processing and increased CPU · Issue #1852 · openhab/openhab-core · GitHub - so please better comment on that issue instead of here in the forum.
That I noticed as well. Often getting errors like the one below without really anything going on that would explain it. In M4 it became worse but that may be a misconception.
@kai could the threadpool change be related ?
2020-11-29 23:27:53.513 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.openhab.core.thing.internal.CommunicationManager@132a993' takes more than 5000ms.