This is exactly what grafana has, that would be very useful indeed.
openHABian sets up the logging to zram.
And I wasn’t recommending constant logging. @DanielMalmgren described an ad hoc debugging exercise and that’s how I intend those two lines to be used. On an ad hoc basis there should be no measurable impact on SD card wear.
It’s missing the .persistence part. See @ubeaut’s code below.
2 Likes
I was looking for the same thing. I ended writing a small js rule to process item history upon each change and output the result in a string item later decomposed into the timeline by a custom widget with repeater.
I should post it on a dedicated thread… (edit: done)
I agree that a built-in way would be great though, I’ll try to create a built-in widget out of it someday.
3 Likes
That looks really good. Good job!
Adding filter would be a lot more involved. I was thinking of revamping it completely, include the widget icons etc, but not committing to doing it yet.
1 Like
Will be nice that rules can be triggered from mqtt without the need of thing and items…
like homeassistant automations for example
- alias: "Controlla luce corridoio da MQTT"
trigger:
platform: mqtt
topic: "Alfred/luci/corridoio/set"
action:
- service: light.turn_{{ trigger.payload_json.powerState | lower }}
target:
entity_id: light.switch_corridoio
- alias: "Pubblica stato della luce sala su MQTT"
trigger:
platform: state
entity_id: light.switch_sala
action:
- service: mqtt.publish
data:
topic: "Alfred/luci/sala"
payload: "{\"powerState\" : \"{{ states('light.switch_sala') | upper }}\"}"
retain: true
i use this to share Bticino Living now (that has no binding for openhab with openhab)
If i want to do the same in openhab i need to create a duplicate of the thing, of the item and link it to mqtt… and a rule… that is very very long and also the number of things and items grow a lot…
Will be Very Very nice to integrate with openhasp for esp32 control panels…
for example if i want to hide a button in control panel i need to create an item connected to the visibility command of this esp32 button…
and if i want to connect a button of the esp32panel to a light i need to create item for this button and then with a rule sincronize with my light…
But this item is totally “Useless” because i will never show in the sitemap…
And also waste my persistence… so i have to create a rule to exlude it from persistence…
Another interesting feature will be assingn more than a channel to an item…
For example
Rollershutter RS_CAMERA "Tapparella Camera [%.0f]" <rollershutter_inv> {channel="shelly:shellyplus2pm-roller:RS_CAMERA:roller#rollerpos",channel="mqtt:topic:MQTT_BATCAVERNA:RS_FINESTRA_CUCINA:position" }
to quickly syncronize an item with mqtt without rules and dummy items…
You can already link multiple channels to items. Use a follow profile on the channel link that should „follow“ the item changes.
1 Like
Err… no.
That is how OH is designed to work, and everything you need can be built with it.
There is absolutely no need to change architecture just because you would like it to behave like Home Assistent or whatever other home automation system.
1 Like
Thank you! i didn’t know!
So something like:
Switch Switch_LuceCorridoio
{
channel="mqtt:topic:broker:comandiCorridoio:set",
channel="mqtt:topic:broker:statoCorridoio:state"[profile="follow"]
}
Should didt the trick!
I suppose that is unidirectional… i mean if the secon channel change the first didn’t…
But is a good start, for semplify many things!
Thanks again!
You can do this without the Item.
On the MQTT Broker Thing you can add event Channels. These are subscriptions, often using a wild card subscription, and that Channel can directly trigger a rule when a message is received.
So you would configure the Channel to subscribe to this esp32panel’s MQTT topic and you can configure a separator character (# by default). Then you can choose this Channel to trigger the rule. Inside the rule there will be an event (how it appears depends on the language) which will consist of <mqtt topic>#<payload>.
The MQTT EvenBus rule template works off of this feature. It subscribes to all messages below a given point and triggers a rule on any received message. The rule parses out the topic and message and uses that information to keep an Item in sync with an Item of the same name on another running OH instance.
But the OH architecture is built with these layers of Items and Things on purpose and for a reason and I can’t imagine that changing for one binding among hundreds. Much of what makes OH unique and powerful is enabled by its architecture.
3 Likes
openhab itself knows nothing about mqtt. It is the MQTT Binding that does. You instantiate the binding by creating a Thing. That’s just the architecture of openhab.
The “standard” way of doing it is by linking it through Item, and you sending a command to the item will cause the item to send the command through a channel to the Thing which then sends it out to MQTT. But you already knew this.
You can do it as @rlkoshak suggested, you could make your rule trigger on the channel directly thereby bypassing the need to have an item. Then your rule can publish an mqtt message also using the Thing, through Thing action.
2 Likes
Hi Everyone,
Have a request for another addition to openhab 5.0
This time, it is about documentation.
What about to add a dedicated entry in the documentation about “Performance, Stability & Issue”.
It can be easy in openhab to have a unstable environment because of misconfiguration of your openhab. I experience this one more time this week because of bad retention policy on persistence layer that made my openhab unstable because of high memory usage and very slow start time. After digging a little inside my instance, I find that I have many influxdb measure with other 1 million entrie that take several hundrer of ms to load, sometime even more then 1s !
Of course, if your search in community post, you generally find good article of how to solve most of the worst case. But you have to know what searching !
The idea would be to have direct pointer to the most usefull entries like:
-
How to configure your java instance correctly with explation of most common parameters.
-
How to use jmap / MAT to take a heap dump, and possibily do a first analysis.
-
How to take thread dump, possibly looking to anormal thread count and cpu usage.
-
How to use openhab console for most common task (already covered in administration guide).
-
How to properly configure persistance layer to prevent excessive cpu and memory usage.
-
How to prevent excessive CPU usage in rule engine.
-
How to fill an issue if something goes wrong : https://community.openhab.org/t/how-to-file-an-issue/.
-
Tips and tricks about what is “standard” memory / cpu usage / openhab start time with minimal addon, and when you worry about your installation and start to fix it if you not in the nails.
-
And other things like that …
Perhaps we can open a separate threads where people will tell about their experience, what can possibly goes wrong, and how they fix it.
And from this thread, somes will time by time pick the most interesting subject, and add entry to the documentation.
What do you thing about this ?
Laurent.
Contributions to the documentation has a nice and low barrier to entry for a new contributor. If you are volunteering then I say go for it.
My only caution is a “properly configured persistence layer” is going to be extremely dependent on the persistence add-on being used. That information probably needs to be in the docs for each add-on and not in the main docs.
Reading your list, I think that most of your more or less buzzword level requests for pre-documented solutions refer to very complex topics and that the docs are not the right place to document them.
Each of those topics heavily depends on the combination of components and their config you individually choose to use such as hardware, OS and Java parameters, non-OH 3rd party component such as database config and individually created rules in potentially various languages including bad user side programming.
Much of this we attempt to cover by bundling a reasonable HW and OS setup to start with in openHABian. Which is already a huge amount work to get over in our spare time that goes unnoticed for the most part.
But to figure out and document how to properly do that for all those optional HW, OS, database and rule language variants that you can use OH with is just impossible and not worth trying.
OH is the joint effort and achievement of a community that you’re now part of.
So as Rich said very well to the point:
Sounds more like a “Troubleshooting” section, but not a bad idea. Will you volunteer to do it?
2 Likes
By the way, there’s a recently reworked troubleshooting guide for openHABian.