A post was split to a new topic: Thermostat issue
@Kai you mention that you plan minor releases of OH3 every 6 months or so; by contrast in OH2 you were releasing new bindings and fixes every 1 month; can you please clarify? It seems to me that 6 months is too slow for innovations in bindings…
6 months is about releases i.e. 3.1, 3.2 just like it was 6 months between OH 2.4 and 2.5.
Anybody that wants anything earlier can choose milestones (due about every month) or even snapshot (daily more or less).
4 Likes
I just upgraded from 2.5 to 3.0 and wanted to clean up some things - like renaming items. Previously I could just change the name in my items file and after a while the name was properly updated - so e.g. was reflected in grafana etc. I did this yesterday, but what was happening is: nothing :). When I look at the UI there also seems the link missing. If I adapt the items file and rename it back, the link is back again.
So I’m wondering now, what is the official way of renaming items now? And: what is the recommendation about linking now? E.g. I created an item in my items file pointing to a thing (like I did before with 2.5). But If I look in the UI, it is not showing as linked. So also the item does not work when I use it in a rule.
I guess I simply missed something in the release notes?
Are you sure that the items as written in the (old) file uses the correct syntax for the channel? If not, this link can’t be used.
Renaming items ( as in using another UID) is not possible, changing the laber however is!
I just want to thank all of you involved in the making (and future maintenance) of OH3.
It looks great and initially I’ve found a lot of nice features. For example I’m considering skipping Grafana in favor of the UI graph views.
Although the UI based programming is not for me, I could really see how it could be a way for non-programmers to start with home automation.
Keep up the great work, I love it 
3 Likes
I have several general questions about the Openhab 3.0 release:
-
Is there an advantage when I transfer my DSL rules from the .rule files into the new rule engine in the main UI? I read somewhere that the rules will be executed (or compiled) faster if they are defined in the UI. Also will there be a syntax check and IntelliSense for DSL rules in the main UI in the future?
-
The new main can also display YAML code for items, things etc. Does this mean that an ESPHome integration could be a possibility in the future like the implementation in HomeAssistant?
-
Sitemaps can now also be defined in the main ui. In my sitemap I’ve commented out several items that are not needed at the moment and I would not like to delete them all because I could use them again in the future. Sadly those commented lines trigger an error in the main ui. Is there another way to disable sitemap items that are not needed in the moment?
-
You can view, modify, enable and disable the rules through the UI remotely. You can split up your rules into a then and but only if clause which sometimes can greatly simplify the rules. I think there already is some syntax checking an intellisensce in the Web UI.
-
No. The mere use of YAML does not make openHAB any closer or farther away from supporting integration with any third part tool or technology. And in this case, the use of YAML is only used by the UI. The underlying data is encoded in JSON.
-
What style of comment did you use? If the sitemap is defined in a .sitemap file does it really matter if MainUI is complaining about it? MainUI can’t show sitemaps anyway, only BasicUI and the phone apps do.
Maybe the question about the comment should be another: How to mark comments in yaml?
YAML only supports inline comments using the number (#) symbol.
ie.
# This is a comment
config:
label: Page Label
sidebar: true
order: "1"
blocks:
- component: oh-block # This is another commentI think the root problem is the UI is transforming between YAML and JSON and that conversion is unable to handle the comments so the comments get stripped out. Yannick posted a comment about that somewhere I can’t find anymore. It’s a technical challenge that has not been solved yet.
Ah, sounds reasonable.
Thanks for the quick reply.
As far as I can see there is currently no dynamic syntax check in the rules (so that errors are highlighted in red) and no IntelliSense in the main UI rule editor. This currently only seems to work with Visual Studio Code. If this should work then maybe there is something wrong with my installation?
Regarding the Sitemap comments. When I create a sitemap in the main UI the code is shown in Javascript just like in the sitemap files and not as YAML. So I was able to just copy & paste my sitemap file in there.
I’ve commented out elements in the sitemap using the // characters. The advantage of the main ui editor would be that I can change the sitemap from a browser and get a nice hierarchical view of the sitemap which would help sometimes because my sitemap has grown quite large.
I’ve upgraded from 2.5 to 3.0 a week ago and everything went well. The upgrade procedure is really excellent, well done!
The only thing that does not work: I can’t open the rules page in the UI.
It just hangs while loading:
I can’t see anything in the logs nor is there anything in the browser console.
I’ve tried with Chrome (including incognito mode), Edge, Firefox and even IE11, at no avail.
Cleared the cache: no change.
rules GET in the API Explore returns the complete list of rules, so they are there. They actually even wor but unfortunately I cannot edit them.
I’m at the end of my wits.
Has anybody else seen such issues or does anybody have an idea what may have gone wrong?
There is for JavaScript. I assumed it worked for Rules DSL too.
I noticed something strange, maybe is a fault in my code but I cant find it. This rule wasn’t fired couple of minutes ago. So i added a logInfo in my rule to check what was going on, and the rule was suddenly fired. I removed the logInfo and the rule is fired again. But it just out of the blue didn’t trigger without any errors in the normal log. I can’t reproduce it again but it happend more often, but when bugfixing you save the file and the problem is gone…
rule "1 - Volume control for Radio and Google audio"
when
Item GlobalVolume received command or
Item RadioVolume changed or
Item GoogleVolume changed or
Item RadioPlay changed or
Item GoogleControl changed
then
if (triggeringItemName == "RadioPlay"){
if (RadioPlay.state == PLAY){
GlobalVolume.postUpdate(RadioVolume.state.toString())
}
}
if (triggeringItemName == "GoogleControl"){
if (GoogleControl.state == PLAY){
GlobalVolume.postUpdate(GoogleVolume.state.toString())
}
}
if (triggeringItemName == "RadioVolume"){
GlobalVolume.postUpdate(RadioVolume.state.toString())
}
if (triggeringItemName == "GoogleVolume"){
GlobalVolume.postUpdate(GoogleVolume.state.toString())
}
if (triggeringItemName == "GlobalVolume"){
if (GoogleControl.state == PLAY){
GoogleVolume.sendCommand(GlobalVolume.state.toString())
} else {
RadioVolume.sendCommand(GlobalVolume.state.toString())
}
}
end
So the strange thing is, that this rule works perfectly at the moment, and also did in OH 2.5.10. But it just didn’t work when I changed the GlobalVolume from habpanel or sitemap.
these are my items.
Dimmer GlobalVolume "Openhab Volume [%s %%]" { ga="speaker" }
Dimmer RadioVolume "Radio Volume [%s %%]" (gRadioVolume) { channel = "mpd:mpd:keuken:volume" }
Dimmer GoogleVolume "Google Audio Volume" (gRadioVolume) { channel="chromecast:audiogroup:Muziek:volume" }
btw i use > { ga=“speaker” } but that doesn’t work, also didn’t work in OH2.5 unfortunately.
[edit]
Happend again in another rule… exactly the same. The heating didn’t turn on, after putting a logInfo to check the state of a string, I saved the file and afterwards everything works as it should…
Can anyone confirm the rules aren’t fired randomly? I’m using the Stable version of Openhab 3.0 on a raspberry pi 4b with openhabian 64bit version (because of the possibility to boot from SSD). I don’t use the new UI for now, only files.
Same again, simple rule. Used to work, now it doesn’t. It’s the same file as the problem with the volume above:
rule "6 - Radio in en uitschakelen"
when
Item Radio received command
then
if (receivedCommand == ON){
logInfo("radio.rules", "woonkamerradio wordt ingeschakeld")
RadioPlay.sendCommand(PLAY)
}
if (receivedCommand == OFF){
logInfo("radio.rules", "woonkamerradio wordt ingeschakeld")
RadioPlay.sendCommand(PAUSE)
}
end
Just added an extra line in the file and saved it, now it works but the log shows something strange:
Hope i’m not the only one with this problem because this isn’t solvable in my opinium…
Not sure if upgrading to 3.1 unstable is smart or more unstable…
[edit] - For now it looks like a onetime only after reboot of openhab, as if some files aren’t loaded correctly. I have around 32 rules files with 227 rules, not sure if that has anything to do with it.
When is the next version planned to be released??
If I remember correct, it is planned to have monthly milestone releases and 3.1 stable should be ready by mid of the year.
1 Like