Discourse plugin for openHAB Community

( ) #1

Hey guys,
following up on an idea discussed with @teichsta at the new forum announcement (Discourse) I have spent a few hours on creating a plugin for Discourse, which adds additional openHAB syntax buttons to the composer toolbar.

The plugin, documentation and all future updates can be found here: https://github.com/ThomDietrich/discourse-plugin-code-fences-buttons

For now, the plugin is not that special. The button “openHAB *.rules code fences” will input markup text for code with php highlighting, which does the trick for now. Implementing the DSL syntax of openHAB into discourse syntax highlighting is another task and everybody is invited to dig into that :wink:

0 Likes

How to use code fences
openHAB now has its own fully fledged discussion forum!
openHAB now has its own fully fledged discussion forum!
(Kai Kreuzer) #3

This plugin is activated now!

Next I would like to see some more specific syntax coloring instead of treating openHAB stuff as php files :sunglasses:

0 Likes

(John Cocula) #4

Just giving a code fence without specifying a language, like:

```
code
```

It would be nice to have a perfectly matching syntax highlighter, but that’s probably more effort than it’s worth. Your solution works great – thanks for providing it.

0 Likes

(Kai Kreuzer) #5

This is the 5th button with the tooltip “code fences”.

0 Likes

(John Cocula) #6

Yes indeed, but my point was regarding using the csv syntax highlighter for items files, and the php syntax highlighter for rules and sitemap files, where those highlighters do not match the syntax, and could (possibly) add confusion. But it’s not unreasonable, either. :slight_smile:

0 Likes

( ) #7

First to make that clear. I also think someone should work on providing openhab syntax highlighting for highlight.js. My plugin can then be adopted to use these new languages! https://highlightjs.readthedocs.io/en/latest/language-guide.html
Volunteers?

I get what you are saying. You are right with items. csv isn’t perfect (wrong formatting of “String” for example), do you know of a better language to use?
With rules, i still think php is a good choice. I can’t tell you why I didn’t select java, seems to work out too and makes way more sense I guess.

Here is the critical part: When using default, so when not explicitly defining a language to highlight, highlight.js will select one itself. The autodetection process is however a bit tricky with unknown syntax, while testing just now the highlighting of the first block switched from one not so good fit to another just while I was typing. That’s why I think default is not a secure option.

Random example (not a real rule):

DEFAULT (bash autodetected):

import org.openhab.core.library.types.*
//import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*
//import org.joda.time.*

rule "Test"
when
    Item BD_Heizung_Preset received command
then {
    //logInfo("RULE", rulename + "Schnellauswahl")
    // Wenn Auswahl auf "F" und update auf "A" 
    if (BD_Heizung_SetMode.state == 4 && BD_Heizung_Mode.state == 0) {
        switch (receivedCommand){
            case 0: BD_Heizung_Lowering.sendCommand(ON)
            case 1: BD_Heizung_Comfort.sendCommand(ON)
        }   
        createTimer(now.plusSeconds(1)) [|
            BD_Heizung_Preset.postUpdate(-1)
        ]
    }
}
end

PHP:

import org.openhab.core.library.types.*
//import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*
//import org.joda.time.*

rule "Test"
when
    Item BD_Heizung_Preset received command
then {
    //logInfo("RULE", rulename + "Schnellauswahl")
    // Wenn Auswahl auf "F" und update auf "A"
    if (BD_Heizung_SetMode.state == 4 && BD_Heizung_Mode.state == 0) {
        switch (receivedCommand){
            case 0: BD_Heizung_Lowering.sendCommand(ON)
            case 1: BD_Heizung_Comfort.sendCommand(ON)
        }
        createTimer(now.plusSeconds(1)) [|
            BD_Heizung_Preset.postUpdate(-1)
        ]
    }
}
end

Java:

import org.openhab.core.library.types.*
//import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*
//import org.joda.time.*

rule "Test"
when
    Item BD_Heizung_Preset received command
then {
    //logInfo("RULE", rulename + "Schnellauswahl")
    // Wenn Auswahl auf "F" und update auf "A"
    if (BD_Heizung_SetMode.state == 4 && BD_Heizung_Mode.state == 0) {
        switch (receivedCommand){
            case 0: BD_Heizung_Lowering.sendCommand(ON)
            case 1: BD_Heizung_Comfort.sendCommand(ON)
        }
        createTimer(now.plusSeconds(1)) [|
            BD_Heizung_Preset.postUpdate(-1)
        ]
    }
}
end
0 Likes

(John Cocula) #8

That makes perfect sense and you have dug deep into it. One last thing I can think of would be to go ahead and generate

```items
your items
```

```rules
your rules
```

```sitemap
your sitemap
```

and then co-opt the closest ones that currently exist and name them items, rules and sitemap. Later someone can actually write proper syntax highlighters for the real languages, and all the old MarkDown will suddenly look better!

0 Likes

( ) #9

“later someone can” :slight_smile:
That’s a good idea. As far as I see it, we would just need to copy one language definition and rename and start to modify it. Afterwards we can build our own highlight.js and bind it with the openhab discourse setup. Done.

What I don’t like about this solution is, that it seems like there is no way, we can contribute openhab-items-syntax into highlight.js and smuggle it into discourse this way. Therefore these modifications in our own fork of highlight.js will always be detached and a hack that @teichsta needs to apply after each discourse upgrade… (i.e. replace a file, possible compatibility problems?)

If you guys think that’s acceptable, I can probably look into the process the next few weeks.

1 Like

(Jerome Luckenbach) #10

Hey @ThomDietrich,

CC: @Kai

The buttons are broken for some time now.
Could it be possible to move/fork the corresponding github repo for this plugin to the openHAB Organisation, so we can fix/update/improve it?

I think @Josar would love to help out, since there is an outstanding pull request from him.

0 Likes

( ) #11

Hey Jerome!
Sorry for my complete absence. I am still in a pretty hectic phase of my life, didn’t even find the time to set up any smart home components in my new apartment :sweat_smile:

I could certainly move the plugin to the openHAB organization, even though it is strictly speaking not openHAB specific but rather defaulted to openHAB use.
Regarding the “broken”: Seems like it’s just the icons which are missing. Part of the solution is already available as an issue: https://github.com/ThomDietrich/discourse-plugin-code-fences-buttons/issues/4

1 Like

(Jerome Luckenbach) #12

Hey Thomas,

This was just an idea.
Maintaining it through the organization would make it easy to share the correct access the interested persons.
That’s why is suggested that.

And of course no problem.
Life has to be in the first place.
Volunteering can be done after that.
I have enough weeks where I also can’t spend the time I would like to.

And yes you are right it’s just the icons, but if one doesn’t know about the feature and can’t see the icons, this is a problem.

Is the addon grabbed from your repo or does it need to be packed for installation here?

0 Likes