@Robert_Burgess Check the persistence wiki (https://github.com/openhab/openhab/wiki/Persistence). I suggest you initially go with just the rrd4j persistence mechanism and get everything working before trying any other method. If you don’t already have this, create a new file in your openhab/configuration/persistence folder called rrd4j.persist. In this file you can use something like the below to get you going:
You can add any items you want in the items section. If you want to graph the historical data for any item (e.g. temperature), then with rrd4j, you will also need to include an ‘everyMinute’ as shown in the temperature example above.
Hope that helps.
(PS I’ve replied in your other post to your query on json).
@smar thanks, I already have the persistence running for keeping a chart of temperatures in the other sitemap. I’ll go ahead and add my other items to here so that it keeps. This will clean everything up nice and tidy I hope and i’ll be smooth sailing thanks for the help!
@smar I’ll take a look at Ohheating widget, as I think that will help with a lot o my issues, at some point later this week, or this weekend.
When I was talking about was specifically the widgets themselves, as there is some amount of data/calculation done in the coffeescripts attached to them. The problem I found is that when using on resource limited devices like the rPi (which I have two: one has dashing, the other openHAB) there is some amount of delay from when a state is sent from dashing to openhab then that state is updated back in dashing. If you’re performing an operation that relies on the current state of an item, and send two quick commands in succession, the state might not get updated between the two times. That’s what I meant about separating the two. I wanted any and all changes of states and calculations thereof in openHAB. This way, I can keep all of these rules in one place: an openHAB rules file.
Also, right now, when you want to perform a new function/task/whatever, you need to create a new widget and its accompanying coffeescript to complete this objective. I was thinking about having one (mostly) universal widget that would simply send a json to openHAB via the ohapp object. The items/values that you want to update can be attached to the widget through the dashboard file like data-items=“item1,item2” and data-commands=“OFF, OFF” or data-commands="+1,+1" This way, you can actually do group like commands without having to create the group/rule in openHAB. I think it make more sense when I can actually put something together to show.
Either way, I think I came to realize that I need a slightly more powerful box than the rPis so I’ll be building that now, and get back to working my dashboard in a new/better environment at a later point. Right now, I’m leaning towards a miniITX build embedded build ( Celeron/Motherboard combo ) inside an antec case with external power supply. Throw in 4 or 8 gb ram and an ssd, and it should perform many times better than the current setup. Plus, I already have uses lined up for the rPis.
Turn the Pis into Kodi boxes I’m running mine in a virtual machine currently located on my local laptop but plan to push it up to my ESXi machine once I get it fixed. its currently down. Keeping them all on one machine the talk back and fourt is almost instant.
@apatel Ok, I think I’m getting a better understanding of what you’re trying to do.
WRT your performance issues, I assume putting dashing on the same rPi as your openHAB is a non-starter? In any event, if you are concerned about consecutive state updates not getting through, one option may be to use mqtt in the middle, instead of the REST api that we are currently using. Again something I did consider at the beginning, but decided against it because (a) I wasn’t experiencing any dropped state updates and (b) it added another layer to maintain. Having said that, I’ve found mqtt (using mosquitto) to be very light-weight and robust and it works well in other scenarios that I use it in.
For tracking states and corresponding calculations, this should most certainly be kept at the openHAB side of things I think. The only calculation that is done on the dashing side with respect to states is when sending a command to openHAB for a particular brightness. However, the dashing widget does NOT assume that any commands it sends to openHAB are accepted (in contrast to the original SmartThings widgets which simply changed the widget status once a command had been sent), and instead waits for an update message to come back from the openHAB rule before it updates the widget status. If you wanted, you could easily make the dashing widget even more abstract by changing the code to just send increment/decrement amounts, instead of the new brightness levels.
WRT a ‘universal’ widget, interesting idea but you need to consider its real life use cases, and whether the widget would have the flexibility that you would need, especially given the increased complexity on both the dashing side and the openHAB rules processing side. Other than simple multi-text widgets, it would be difficult to present a widget mapped to multiple items. Say for example you had a dimmer. What other item would you map to the dimmer widget? Heating temperature etc are obvious ones that this works for, as would say weather widgets. But then your openHAB rules would still have to manage multiple items one way or other. Your ‘incoming’ openHAB rule would need to breakdown the message to identify the relevant items, get the item state requirements and post this onto the openHAB bus. Once the items are updated, your outbound openHAB rule would need to form an appropriate json string and then send this back. However, remember that openHAB will be updating items one at a time unless they are part of an openHAB group. Thus the openHAB event bus will be firing each item state change individually. Your rule for sending messages back to dashing would need to factor this etc. The receiving dashing widget would then equally process the incoming message, interpret the relevant item states and populate its values accordingly. Also formatting/presentation would ideally have to be managed by the ‘universal’ widget. Again, additional complexity and processing all round.
Anyway, certainly no harm in trying out! I look forward to seeing what you come up with.
@smar thank you for the reply. I think its time just to re-purpose the rPi-s and just get get a proper server box and use it to host openHAB/dashing as well as my plex server (which now runs on my main computer). I’m going to return stuff I just ordered, and build a bigger box that can expand with my needs.
WRT to the other, thank you for the information. I think i’m going to hold off on this, and just get an operable system up and running. I’m actually turning my attention to something to a display widget for Waze travel times to certain location (not openHAB related).
Build a nice ESXi host amd this way you can just add machines as needed. you cam grt older decommissioned servers cheap online then use that. i got a dual xeon quadcore with 16GB of ram coming i got for a couple hundred bucks. i have another machine that just died but i ran mythbuntu, an active domain controller a media server for my Kodi boxes as well as a 3CX phone server for my home business. plus they can expand to fitthatthing you could need in a home.
@smar
what about your Ohdimmer?
I found something in the coffeescript. (ohdimmer.coffee)
It has a strange behaviour
Clicking the button won’t toggle the green indicator.
Only the slider will change it.
postState: ->
newState = @toggleState()
$.post '/openhab/dispatch',
deviceId: @get('device'),
command: newState
//why is it toggling twice? @toggleState()
ready: ->
when @toggleState() is not there the Green indicator works fine.
@apatel You’re most welcome, and good luck with the rebuild. As suggested by @Robert_Burgess, I also have had good experience with the esxi route, running on a low power HP Microserver (gen 8), which I picked up for next to nothing with one of their regular cashback offers (not sure where you are, but there’s one on at the moment here in the UK).
@3DJupp That extra @toogleState() was left in by mistake - thanks for picking it up! I will get it corrected. However, as it is called after the dispatch, it doesn’t actually (visually) do anything from what I can see, hence the reason it slipped through. On my system, the green indicator works irrespective of this additional command. What this extra command is doing is toggling the internal ‘state’ variable to an incorrect value. But because the visual state is always coming from openHAB (which would then overwrite this state value back to the correct value), it wasn’t showing visually and so I hadn’t picked it up before. Thanks again.
Hey,
with more and more OH widgets circulating wouldn’t it make sense to move to the Dashing way of distributing widgets?
At the end of the page is a great explanation how to do this. As I understood its also possible to easily share/install those widgets then with dashing install $SOME_ID.
@smar I believe I spoke to soon. I just was setting up a page for all my lights in my livingroom and I noticed something that I"m curious if its how the widget sees it. Once I send an ON command OpenHAB is immediately setting the values to 100% even though you can tell they are still at the 70% state they were when I hit my group off command. So I will need to declare the variables and save the state before but I can’t seem to get them to save. I declared state1 and state2 as variables at the top of the rule file.
@smar@Robert_Burgess I dont know nearly enough of about how to implement that sort of environment, and honestly dont want to learn that right now. I’m in the US (Manhattan) and havent seen those HP boxes that cheap yet. Here’s what I’ve ordered/building: core i5 (3Ghz - i had one laying around) on a simple asus MB, with 8gb ram and 250GB ssd, in a fractal node 304, which is the most expensive part of the build because i had to get it from best buy. That should be more than enough for a seedbox/openHAB/dashing/Plex Media server, etc, right?
Also @smar, for the Ohweather widget, I was working on a ruby script to pull Waze traffic data every morning between 7-9 and updated every minute, and found that this can be accomplished using scheduler with cron inputs.
I’ve updated the weather widget to look something like:
SCHEDULER.cron */5 7-11 * * * do |job|
and then added other schedulers for different times during the day. for different times. Just letting you know that this can be accomplished in that manner.
@apatel implementing is very very simple and you could install it on that box you are building. Im very interested in the traffic info. I’d actually like to possibly create a seperate traffic widget to display on the dashboard. I plan on taking an old tablet and walmount it right where I come in and out of my apartment and I can readily see this while leaving would be a nice.
@Robert_Burgess I haven’t built the widget side yet, but I have the code pretty much ready to get and parse. I can shoot it over tonight if you want it. I want the same thing for the morning. After I get this done, next would be to request an UBER with a button right next to it. I’ve done my reading on that side already, and shouldn’t be to bad.
Its very crude/simple, and based on parsing the response you get from this request:
@apatel I’m not seeing any response from that when I click the link but I will definately take a look. Are you going to do this directly in the dashboard or you placing this in OpenHAB and setting data and then having the widget call the information? Just curious, I’m going to look at how to get JSON data from them as well for my specific locations and play with a layout that is in my head for a nice 2x1 widget.
The Uber request buttons nice idea to, not something I need but awesome to say the least. The integrations with this software and dashboard are endless
This is a ruby script that goes into the jobs folder of the Dashing project. Every minute between 7 and 11, it makes get the info, then sends it to the widget. From there it can be displayed.
(Probably should take this off the openHAB thread as it has nothing to do with openHAB).
@waitz_sebastian Can certainly have a look at it, but in essence it seems to be just creating a github gist. Also we would ideally have to package all the underlying dependencies with each widget (e.g. the lib and job folders as well as the assets), in case someone just downloaded a single widget. Finally with the number of different widgets we have, we may end up swamping that page with our widgets if we posted them individually It may be easier if any of us that creates a widget generates a pull request, and I can then merge the widget into the existing repo.
@Robert_Burgess This may depend on your devices. The original reason I had forced the Ohdimmer widget to go to 100% on toggling to ON is because I have a few X10 dimmers in my set up that always go to 100% when switched on, irrespective of the actual brightness level that I send. My z-wave dimmers on the otherhand (and some of my extended X10 devices) retain their previous state, and will return to this value when switched on with the ON command. To get around this and provide some degree of consistency, I forced the widget to send 100% each time, following which I would adjust the brightness to the level required. I’m not sure if this is the same problem at your end, but if it is, the only other way would be use an openHAB rule that intercepts the ON command, posts an update to the device to let it know that its state is at 100% and then do another sendCommand to change the brightness to the required level. Convoluted and not ideal, but it does work (I’ve done it). If this is not your problem, we’d have to look further into your logs to understand what is going on.
WRT your query on running openHAB with security, sorry I have security enabled but only on remote connections. As all my dashboard controllers are local, I haven’t needed to worry about security so haven’t looked into this. I would guess though that this would come down to what openHAB’s REST api supports. If this enforces security, we would probably pass the userid/password in the rest command url. You would thus have to update the ohapp class object accordingly in the dashing side.
@apatel The hardware you list will certainly be more than enough for your openHAB set up (my HP box is running on a celeron processor). I run my Plex server on a separate box so that it can do multiple transcodes at the same time etc. However, my brother has his plex running on a virtual machine on his HP microserver along with his openHAB etc, and says that it has been working fine since he set this up about 6 months ago. Admittedly he doesn’t do much concurrent transcoding as most of his playback is raw/without transcoding.
WRT the ohweather widget scheduling, thanks for letting me know. Also as above, if you want me to merge it into the main repo, please rename the widget to differentiate it from the existing weather one, and send me a pull request on github. Same goes for any of your other widgets you’ve been developing.
I’m running mine in a virtual machine currently located on my local laptop but plan to push it up to my ESXi machine once I get it fixed. its currently down. Keeping them all on one machine the talk back and fourt is almost instant.