I got it, per your suggestion I went and redownloaded and when I opened it looked like it had more in it. Placed it where I wanted, ran bundle install and boom now I got the default dash. Now thats to this though I will be spending hours tonight doing this haha. I have the terminal showing me the temperature is being pulled in but yet the dashboard is not displaying the data, the clock works but thats about it.
@smar do you know how/where the updates sent by openHAB to dashing via the rules are handled?
Iām trying to get two pieces of data into one widget. For example, I have a widget for the living room temp and I want to include the thermostat setting there as well.
Its no problem if i use a data-* from dashboard/default.erb to the Ohtemp widget and updates it on initial load. however, any updates made that item doesnāt make it back to the widget. Any idea where the data updates are handled on the dashing side?
EDIT: NEVERMIND - i just added a rule to send avariable that had both, and just parsed it on dashing side. something like this in the coffeescript
@accessor ātargetā,
get: -> @_target ? @get(āstateā)[3ā¦4]
set: (key, value) ->
@_target = value
@accessor ātempā,
get: -> @_temp ? @get(āstateā)[0ā¦1]
set: (key, value) ->
@_temp = value
ap
I got the weather to work, while digging through all the files I had noticed that the app.temperature and the like never gets set if the length of currentconditions is blank. I was only working on temperature at first because I have A LOT of weather bindings. So this is up and working 
anyone else that might have an issue with it this might prove useful.
Iām looking to also do something like this. Could you show me a screenshot of how yours looks? I was thinking Iād have to create multiple widgets to accomplish what I want but Iād love to see how this is working. I was thinking of creating a whole new page for the weather that you can see when you click the weather widget
@smar @apatel a quick question and maybe Iām missing something in setup. Iām not sure on this but I setup a button for on off and a dimmer for my living room and bedroom lights. If I turn off the lights with the button the dimmer will still show the previous brightness Is there a way this can update to show that it is off and the brightness show 0 but still save the previous value so when clickong on again this updates?. That or is there a way that the dimmer can act as a switch as well. I noticed clicking a dimmer will shut off my lights but the brightness doesnāt update to show its off, it puts it at 100 and then shuts the lights off. You than have to click the + icon to turn the light on however this does it at 100. Looking at the toggleState button i see why its setting it to 100, however how can I get the previous state and save it to a variable to be used later. So when it is set to 50% and i click it display 0% and turn lights off, click again set to previous brightness and update the dash board.
@apatel It would be great if you can share the full code added along with an example on how you managed to fetch two items into the temp-widget.
Sure. Hereās a link to the files: https://drive.google.com/file/d/0B2wRI0BstQFtbTEtWm8yQTdKSU0/view?usp=sharing
In OpenHab, I already had these two items defined for the current temp and target temp:
Number Office_Temp
Number Office_Temp_Target
I then created a new item so that I could concatenate them:
String officeTempTarget (gDashboard)
And in the rules I added the following:
rule ācombineOfficeTempsā
when
Item Office_Temp_Target received update or
Item Office_Temp received update
then
officeTempTarget.postUpdate(Office_Temp.state.toString + " " + Office_Temp_Target.state.toString)
end
Finally I added the following into the dashboard/default.erb file
<li data-row="11" data-col="3" data-sizex="1" data-sizey="2"> <div data-id="officeTempTarget" data-view="Ohtemp" data-title="Office" data-device="officeTempTarget"></div> </li>
And hereās how it looks at present:
1 Like
That is awesome. Would you mind sharing your version of the weather widget? This is exactly what I was looking to do with mine I thought about a new page but this is definately a lot cleaner looking. Where are you pulling Clear throughout the day from? I use Wunderground and not sure I see something like this in the feed but I could be wrong but yes if you could share that Iād very greatful. Also your lamp buttons do they react when clicking Lights Low and Lights High?
I donāt mind sharing. See: https://drive.google.com/folderview?id=0B2wRI0BstQFtU2t4VzEyWkhHT2M&usp=sharing
One thing though, and I canāt make this clear enough, Iām not very good at this, and almost all of this is a hack job, so, there are a issues that can/will happen. It may look nice, but it can get ugly too. But this is alot more than the weather widget, as i made a good amount of additions to the lib/jobs files as well. Also, Iāve made so many tweaks/changes along the way that it may be hard to follow (it is for me sometimes).
The clear throughout the day is from forecast.io, but I also use Yahoo for current weather. On my to do list, is actually to go through and debug the best weather data from all the available ones.
String Weather_Condition_Long āCondition [%s]ā (Weather) {weather=ālocationId=home, forecast=1, type=condition, property=textā}
For the Lights Low / Lights High, I was getting tired of trying to debug the coffee scripts that I created a new widget in my called Ohsendcommand. It doesnāt query state, or anything else, it just sends one command and I used the data-icon to state the command I wanted to send. This way, I could do more complex scripting in openHab via the rules. Now that I think about this, you could actually use this to achieve your task vis-a-vis previous light setting. And store the previous value in a dummy item thatās only updated by your rule, when the lights turn off.
<li data-row="11" data-col="7" data-sizex="1" data-sizey="1">
<div data-id="Light_office_Scenes" data-view="Ohsendcommand" data-title="Lights Low" data-device="Light_office_Scenes" data-icon="1"></div>
</li>
And I have a rule in setup in Openhab for that item, like so:
var String lightsRelax=ā71.91208,84.35754189944134,70.19607843137254ā
var String lightsFullBright=ā76.92307692307692,15.294117647058822,100ā
rule āoffice_Scenesā
when
Item Light_office_Scenes received command
then
var String office_floorLamp
switch receivedCommand {
case 0: {office_floorLamp=āOFFā}
case 1: {office_floorLamp=lightsRelax }
case 2: {office_floorLamp=lightsFullBright }
}
Light_office_hueLamp_DimmerColor.sendCommand(office_floorLamp)
end
Light_office_hueLamp_DimmerColor is a Color item
I may have missed, one or two or ten things in here, so just feel free to ask. I might not have nor remember the answer tho.
1 Like
@apatel that makes sense to do it with Rules. I started thinking about it after i walked away and let myself kind of reset for a moment. The dashboard doesnāt like grouped switches and seems to be unable to read the state of the switch. I get this over and over in my logs Uncaught TypeError: Cannot read property āreadyStateā of undefined Iād like to actually pull the status on it though and I just need to play a little more. I have a better grasp of whats not occuring and have a lot Iāll be doing. I think Iāll free up the thread so others can also post different things. Iāve tweaked your weather a little bit to add the days actual high and low that I track. Again thanks for the help heres my dash now 
@apatel Great to see you taking this forward! WRT widgets with dual (or more) values, I would do it the same way you have in terms of using a separate openHAB rule to concatenate results from one or more items, and then posting that to dashing.
However, one thing I would probably do different is that rather than using simple string concatenation of the item states, I would format each itemās state into a json parameter, and then have the concatenated state as a json string comprising of two (or more) item states. That way you can parse the data accurately in your coffeescript without having to guess/assume pre-fixed string sizes (e.g. @get('state')[0..1] and @get('state')[3..4]). In fact, I was mulling over taking this approach for the weather widget, which would then mean we can take out the 5 minute timer in the dashing job.
Hope that makes sense.
@Robert_Burgess Iām not quite sure what you mean when you say that the dashboard does not like grouped states. In fact, on my own dashboard, the widgets Outdoor Lights, Living Room Lights and Front Room Lights are all groups in openHAB, and thus represent multiple light items in each group. If you post your rule code, we might be able to spot what is going on with your undefined item error.
@smar here is the rules I have setup.
/** 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)
end
/* Living Room Group On/Off Switch */
rule "Living Room On/Off"
when
Item Light_LivRoom_AllLights_Sw received command
then
var String swVal = "OFF"
if(receivedCommand==OFF) swVal = "OFF"
if(receivedCommand==ON) swVal = "ON"
sendCommand(Light_LivRoom_Steps_Sw, swVal)
sendCommand(Light_LivRoom_Candles_Sw, swVal)
postUpdate(Light_LivRoom_Steps_Sw, swVal)
postUpdate(Light_LivRoom_Candles_Sw, swVal)
end
In my items file I just have the following:
/* Lights */
Switch Light_LivRoom_AllLights_Sw (LivRoom_AllLights)
Dimmer Light_LivRoom_AllLights_Dim <hue> (LivRoom_AllLights)
Switch Light_LivRoom_Steps_Sw "Steps On/Off" <hue> (LivRoom, Lights, LivRoom_AllLights) {hue="1"}
Dimmer Light_LivRoom_Steps_Dim "Steps Dimmer" <hue> (LivRoom, Lights, LivRoom_AllLights) {hue="1;brightness;40"}
Switch Light_LivRoom_Candles_Sw "Candles On/Off" <hue> (LivRoom, Lights, LivRoom_AllLights) {hue="2"}
Dimmer Light_LivRoom_Candles_Dim "Candles Dimmer" <hue> (LivRoom, Lights, LivRoom_AllLights) {hue="2;brightness;40"}
Also I guess my question is how does dashing get an update to say hey this state has changed? Such as if I click my group switch how do I have it automatically update the single items state within the dashboard? I think I might get away from single switches if I could get the dimmer to work how iād like. I noticed that even if I switch something off or on the Dimmer percentage status still stays which is actually how iād like it. The issue I guess is that dimmer toggle doesnāt work 100%. Clicking it will turn it off, which is great however what Iād like to see is this. When turning off show the percentage at 0% and then clicking the now blank circle again will bring it back to the previous percentage and set the lights to that. My guess is having to rework the coffee script? Thanks for the input and Iāll continue to play with this.
Add the group gDashboard to those itemsd that you have. They will then get updated in dashing if you added the dashboard.rule file to your rules folder in openhab.
EDIT:
Sorry, I was confused here initially. Assuming in Dashing Widget the device name is Light_LivRoom_AllLights_Sw What you need to do is actually update Light_LivRoom_AllLights_Sw ==āOFFā in your rules. And make sure that Light_LivRoom_AllLights_Sw is in the gDashboard group, this way it will openHAB will update the state of the change.Does that make sense?
@Robert_Burgess how did you get it to calculate the days in the forecast like that? Thats really slick and I would like to implement something like that.
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?
@naturalblaze see: Dashboard UI suitable for tablets
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
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()
@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
@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 bypostUpdate(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).
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
Thanks! apatel and Robert_Burgess that did the trick.