Dashboard UI suitable for tablets

Robert_Burgess · September 14, 2015, 9:31pm

See a couple replies up, this was done by apatel, i tweaked a little for the weather but he attached what he did and I just changed it locally on my end to match the information I was pulling.

Also speaking of @apatel thank you for that. I seemed to of not realized that in my dashboard file my item and id were not matched. This is why they were not updating. The only thing seems to be for some reason my living room lights dimmer does not have a default state of off or on and likes to show uninitialized. What I like though is it seems to work where clicking the switch button my dimmer works how I want it to, so I’ve removed the toggle feature on it so I dont do it on accident. How do I make sure this group dimmer does not go uninitialized?

apatel · September 15, 2015, 12:41am

@naturalblaze see: Dashboard UI suitable for tablets

@Robert_Burgess

Ok. Light_LivRoom_AllLights_Dim is not actually linked to anything right? So, take the example where you restart openHAB: An item that is linked to a hue light, like Light_LivRoom_Steps_Sw, are uninitialized when openHAB start, but openHAB will poll Hue and get there states, and populate. There’s nothing out there telling Light_LivRoom_AllLights_Dim what it state is. I mention that because the same thing applies when you turn on and off the hue lights from the native hue app. It goes back to whatever it was.

That’s not a problem for the Light_LivRoom_AllLights_Sw because it only has 2 states.

What I would do (and there probably is a better way), is create another item called Light_LivRoom_AllLights_Dim_PREV and add save the current state. Then when it gets an ON command: Light_LivRoom_AllLights_Dim = Light_LivRoom_AllLights_Dim_PREV

apatel · September 15, 2015, 1:19am

Interesting you mention JSON, as that’s how I approached it in my first attempt. However, I didn’t and still don’t know/understand JSON well enough to accomplish what I was trying to achieve. Would you mind sharing an example of the construction of the JSON in openHAB? (just guessing here, but you would send, JSON - >item, state, item, state ?)

This actually leads nicely to my second topic/comment/(existential rambling) that Id like to get your thoughts on: Ohsendcommand, as a sort of robust button/toggle. I think this might be a very interesting and (what I like more) cleaner/organized way to approach a dashboard that actually isn’t in openHAB.

The way I envision it working is that Dashing handles the UI side only and all the data is sent to a single item in OpenHAB, and the sentCommand contains the item(s) and command(s) translated and posted. This should avoid all complex scripting in what could be many dashing widgets (and more importantly RUBY). For example, if I want to turn the temp up on my thermostat, i dashing would send in JSON the item and the command ‘+1’, which would be translated and posted to the item in openHAB. The items/commands could be attached to the widget in the default.erb file via data-*. Then the item is updated, and posted back to dashing (if it needs, and then data-id would be the name of the item being updated in openHAB).

In dashing, you could assign a data-class, via SASS variables create the widget, with its style. In theory, you could run a simple +/- dimmer as well, have to commands, and assign where they go in the widget.

Does this make sense? Or am I wasting my time here?

If this does make sense, as I said above, I’m quite unfamiliar with JSON, so will ramp my knowledge up on it next. If you could provide any examples, esp. for ruby/coffeescripts, that would help tremendously. I think I saw a few examples in openHAB about parsing JSON, so I should be good on that front.

Thanks in advance.

ap

Example using how its currently designed that updated a scene that is set via openHAB rules. Data-icon is set to the command I want to send, which is going directly to a rule now, but would be sent to the dummy item i proposed above.

In default.erb:

   <li data-row="7" data-col="7" data-sizex="1" data-sizey="1">
    <div data-id="Light_livingRoom_Scenes" data-view="Ohsendcommand" data-title="Lights Low" data-device="Light_livingRoom_Scenes" data-icon="1"></div>
  </li>

And the coffeescript:

class Dashing.Ohsendcommand extends Dashing.ClickableWidget
constructor: ->
super

@accessor ‘command’,
get: -> @command ? @get(‘icon’)
set: (key, value) -> @command = value

sendCommand: ->
myCommand = @get(‘command’)
$.post ‘/openhab/dispatch’,
deviceId: @get(‘device’),
command: myCommand

ready: ->

onClick: (event) ->
@sendCommand()

Robert_Burgess · September 15, 2015, 3:39am

@apatel I’m not to familiar with JSON and never used it but seeing how useful it is and this being my new project I’ll be reading up on it. For the Uninitialized state I’m just not worried about seeing as like you mentioned its a dummy switch so only when my system gets reset will this possibly be an issue. In which case I found hitting one of the switch elements works fine to give it a state. I’ve updated my rule to the following:

/** This rule is to control all lights in living room on a dimmer */
rule "Living Room Dimmer"
	when
		Item Light_LivRoom_AllLights_Dim received command
	then
		var Number bVal = 0
		if(Light_LivRoom_AllLights_Dim.state instanceof DecimalType) bVal = Light_LivRoom_AllLights_Dim.state as DecimalType 
			
		if(receivedCommand==INCREASE) bVal = bVal + 25
		if(receivedCommand==DECREASE) bVal = bVal - 25

		if(bVal<0)   bVal = 0
		if(bVal>255) bVal = 255
		
		sendCommand(Light_LivRoom_Steps_Dim, bVal)
		sendCommand(Light_LivRoom_Candles_Dim, bVal)
		postUpdate(Light_LivRoom_Steps_Dim, bVal)
		postUpdate(Light_LivRoom_Candles_Dim, bVal)
		
		if(bVal>0) postUpdate(Light_LivRoom_AllLights_Sw, ON)
		if(bVal==0) postUpdate(Light_LivRoom_AllLights_Sw, OFF)
end

This keeps the dashboard 100% up to date. Soon as I hit 0 on my group dimmer it sets the group switch and both individual switches to off. Turn up the dimmer to say 50% then click the group switch it will set the dimmers to 0 and switches to off status. Then click the Group on switch and the lights come back on with the previous state in tact and all the dimmers and switches update. There may be a small 1 to 3 second lag sometimes but this could be due to the resources of the machine right at this moment. It even works if I use the default interface or app dashboard updates right away so I’m not VERY happy with this.

As far as your idea with JSON it sounds correct, you would have a coffee script to send information. Again I’d need to look more into but would love to test with you. I’d actually want to do somethign like that when I get a Ecobee smart thermostate have a 1x2 widget with the current temp on the left and the up and down options on the right to go up and down a degree

smar · September 15, 2015, 8:33am

@Robert_Burgess Is your group switching/dashboard refresh issue resolved now? A couple of small thing I noticed in your rules that don’t impact their functionality, but I was curious as to your reasonings:

You seem to be doing a postUpdate immediately after a sendCommand for the same item (e.g. sendCommand(Light_LivRoom_Steps_Dim, bVal) is followed by postUpdate(Light_LivRoom_Steps_Dim, bVal)). Is there any reason for this?
You are defining string values of “OFF” and “ON”, and then sending these as commands to your ‘_Sw’ devices. You could instead just send the states OFF and ON directly.

Neither of the above should impact how it works, just optimisations.

Finally, with regards to initial states, you can use persistence to restore your previous state to any items you define. This way, after restart of openHAB, the items continue from their last known state and do not have an unitialized state.

@apatel JSON (http://json.org/) is actually very straight forward and in its simplest form, you can think of it as a group of items and their values. Items are defined in double quotes and have a colon symbol before their value. String values also have quotations, whereas numbers normally do not. Item/value pairs are separated by commas. You can also have multiple (nested) levels of items and parameters.

A simple example may be:

{ "temperature" : 22,
  "target" : 21,
  "units" : "centigrade" }

As an example of using this with the dashboard, if you check the github repo, I have added a new widget Ohheating and updated the openHAB rules file to use this. The rules are probably not as tidy as they could be, but a quick attempt to show you a way of sending two properties (temperature and target) to a single widget. If you do use the rules as they stand, any ‘combination’ strings you create should be prefixed with “JSON” so the main dashboard rule concatenates correctly.

WRT your thoughts on the Ohsendcommand widget, if I understand correctly you are looking for a way to have a single widget that does all the processing for item data to/from openHAB. If so, I am not sure why you would want to go through all this. At the moment, all the communication is being done through a single object, ohapp. All this object does is the sending/receiving. We can add whatever additional ‘routes’ as required (have a look at Sinatra http://www.sinatrarb.com/ which is integral to dashing), though for the current widgets, I have’t really seen any need to add anything further to this object. Moreover, to-date, I haven’t found a need to do much in Ruby either after the the initial set up. Yes, coffeescript is required for each widget, but this gives us the flexibility to define widgets as we need AND provides the separation of UI and openHAB backend that you refer to.

By going through a single widget (sendCommand), which itself is going through the Ruby ohapp object seems to be adding an additional layer of processing and complexity on both the dashing side AND the openHAB rules side. It is quite possible I’m missing your point entirely…

EDIT: Also if you have a look at the html/coffeescript/scss for the new Ohheating widget, you’ll see an example of how to dynamically apply css styles depending on the state of the widget (target-style in this example).

Robert_Burgess · September 15, 2015, 3:41pm

Hey @smar yea, once I made these few tweaks it worked great. As far as postUpdate and sendCommand being right after each other I did this on accident but noticed that my Android Apps wouldn’t update without both. I could of been doing something wrong but with both in there my single dimmers update immediately after moving the slider on my group dimmer. The group on/off switch I do see that it is not needed. All in the tinkering of the rule but I’ll be updating that to just send directly instead of a value. Thanks for that. I’m not sure how i’d do the persistance thing but that sounds like an option for sure.

Also I’m interested in JSON as well, I’m working on a rule that I wanna send JSON to. If you could give your input here as well JSON Rule Help, Transform? it’d be appreciated. With JSON I believe a lot of really nice things can be achieved and looking forward to seeing how these work so that I can get into it

naturalblaze · September 15, 2015, 8:47pm

Thanks! apatel and Robert_Burgess that did the trick.

smar · September 15, 2015, 9:06pm

@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:

Strategies {
	everyMinute	: "0 * * * * ?"    
	default = everyChange 
}

Items {
	* : strategy = everyChange, restoreOnStartup
	gDashboard* : strategy = everyChange, restoreOnStartup
	CH_Indoor_Temp : strategy = everyChange, everyMinute, restoreOnStartup
}

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).

Robert_Burgess · September 15, 2015, 9:17pm

@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!

apatel · September 15, 2015, 9:35pm

@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.

Robert_Burgess · September 15, 2015, 10:33pm

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.

l_grave · September 16, 2015, 7:17am

I use an Intel (Celeron) NUC as an openHAB server, that’s propably cheaper and more quiet than a custom mini-itx system.

smar · September 16, 2015, 9:22am

@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.

apatel · September 16, 2015, 3:34pm

It was $142 for the board/chip+case vs. $130 for the NUC, so its about the same.

apatel · September 16, 2015, 6:43pm

@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).

Thanks for the info again.

Robert_Burgess · September 17, 2015, 2:27am

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.

3DJupp · September 17, 2015, 2:39am

@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.

smar · September 17, 2015, 7:42am

@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.

waitz_sebastian · September 17, 2015, 9:12am

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.

Robert_Burgess · September 17, 2015, 4:56pm

@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.