Dashboard UI suitable for tablets

@smar I have not edited any coffeescripts. I am using the correct erb file.
But if I do a clean “dashing new dashboard”, I get a website with
“Try this: curl -d ‘{ “auth_token”: “YOUR_AUTH_TOKEN”, “text”: “Hey, Look what I can do!” }’ \http://192.168.0.14:3030/widgets/welcome
Might be something wrong with my installation?

G

I’ve created a pull-request on Github for that.

Anyone an idea about the coloring thing or seen the same when looking at chrome DEV console?
Thanks

@waitz_sebastian Have a look at the ohalert widget. I put that together for exactly this purpose. Also the ohheating highlights the bottom bar in different colours depending on the temperature etc.

@gaute91 If you do a clean dashboard, then that response looks probably correct. This sort of thing is very difficult to debug via such forums, but if you follow the instructions for installing the repo, you should get the default dashboard from the repo (http://192.168.0.14:3030/default). Maybe try putting the full url in and see what happens?

Sorry, I haven’t tried this yet. In theory if it is working in openHAB and we can control it via REST commands, the dashboard should be straight forward. WRT the numeric values, can you give an example of what it is you have and what you are trying to get to. I suspect that you will probably need to do any transformations in the widget’s coffeescript.

Yes, I recall they were originally green in the initial SmartThings forum, but were later changed by the owner of that repo. I haven’t looked but it may well be some CSS in the assets folder.

@Robert_Burgess Looks like installing Play Store on the new Amazon Fire has been solved! http://forum.xda-developers.com/amazon-fire/general/installing-google-framework-playstore-t3216122/post63101324#post63101324

1 Like

@smar I tried to delete the dashboard folder, and do another git clone, edited config.ru and ohapp.rb and did bundle install. Still getting the same response. You have any ideas, or should I just do the whole installation of ruby again?

Okey,
So i finaly got around and did all my rubys and dashboard install again.

And

It works :slight_smile: thanks!

I would like to point to this discussion - Different take on client UI (Android for now) - which is about a native Android dashboard-like client, looks really nice.

@gaute91 Great to hear you’ve got it working!

@belovictor Thanks for the heads up.

So I managed to get my mappings working “somewhat”. I’m having a weird issue though. For the Thermostat mode there are 3 possible settings 0=Off 1=Heat 2=Cool. I’m using something similar to the dimmer +/- to control the settings but if I hit - when the mode is already 0/Off I loose my mapping and same with + when the mode is 2/Cool. Its strange because the logs show it’s sending the correct numeric setting and if I go back the other direction then the mapping comes back. Any help would be great my coffee script is below.

  class Dashing.Ohsetmode extends Dashing.ClickableWidget
  constructor: ->
    super
    @queryState()

  @accessor 'state',
    get: -> @_state ? '0'
    set: (key, value) -> @_state = value

  plusLevel: ->
    newLevel = parseInt(@get('state'))+1
    if newLevel > 2
      newLevel = 2
    else if newLevel < 0 
      newLevel = 0
    @set 'state', newLevel
    return @get('state')

  minusLevel: ->
    newLevel = parseInt(@get('state'))-1
    if newLevel > 2
      newLevel = 2
    else if newLevel < 0
      newLevel = 0
    @set 'state', newLevel
    return @get('state')

  levelUp: ->
    newLevel = @plusLevel()
    $.post '/openhab/dispatch',
      deviceId: @get('device'),
      command: newLevel    

  levelDown: ->
    newLevel = @minusLevel()
    $.post '/openhab/dispatch',
      deviceId: @get('device'),
      command: newLevel     

  @accessor 'thermode-map', ->
     if @get('state') == '0' then 'Off'
     else if @get('state') == '1' then 'Heat'
     else if @get('state') == '2' then 'Cool'

  queryState: ->
   $.get '/openhab/dispatch',
      widgetId: @get('id'),
      deviceId: @get('device'),
      deviceType: 'temperature'
      (data) =>
        json = JSON.parse data
        @set 'state', json.state
    
  postState: ->
    newState = @toggleState()
    $.post '/openhab/dispatch',
      deviceId: @get('device'),
      command: newState     
      @toggleState()

  ready: ->

  onData: (data) ->
    debugger

  onClick: (event) ->
    if event.target.id == "level-down"
      @levelDown()
    else if event.target.id == "level-up"
      @levelUp()

@naturalblaze Could you attach a zip file of your whole widget, including the coffeescript/html/css. That will make it easier to check your actual code.

I actually just modified the widget so instead of staying on “Off” or “Cool” it just scrolls around and I don’t loose the mapping at all. I think I like it better that way but I appreciate the response. I have both my Z-Wave Radio Thermostat CT100’s working in the Dashboard now with the ability to make adjustments as I can through OpenHab. If anybody is interested I can post my configs for them. I have 5 different widgets I created for the Thermostat.

  plusLevel: ->
    newLevel = parseInt(@get('state'))+1
    if newLevel > 2
      newLevel = 0
    else if newLevel < 0 
      newLevel = 2
    @set 'state', newLevel
    return @get('state')

  minusLevel: ->
    newLevel = parseInt(@get('state'))-1
    if newLevel > 2
      newLevel = 0
    else if newLevel < 0
      newLevel = 2
    @set 'state', newLevel
    return @get('state')

2 Likes

Hey all,
I’m trying to diplay the numbe of open windows as widget on the Dashboard. Thus I’ve configured an active group in OH that properly displays the number within OH UI,

Group:Contact:OR(OPEN, CLOSED)  agFenster    "All open Windows [(%d)]"                <contact>

But when adding the gDashboard group to populate info towards Dashing, I receive multiple errors in openhab.log. Secondly I’ve tried using the Ohtext or Number widget. Both only show UNKNOWN or OFF instead of the number.

Does anyone have such setup already running and give me a hint? Or any idea how to make this work?
Thanks much.

Hi @waitz_sebastian.

What are the actual errors you are getting in OH? If the data is not being posted correctly to dashing, the two widgets you tried will not be able to show the number.

Hey Smar,
After further troubleshooting it seems, that you cant add a group to an active group. As soon as I do this configuration every subsequent item config is gone and I receive error messages like the below once I access the OH UI and items should be rendered.

2015-11-18 21:23:28.957 [ERROR] [o.u.i.items.ItemUIRegistryImpl] - Cannot retrieve item Date for widget org.openhab.model.sitemap.Text
2015-11-18 21:23:28.959 [ERROR] [o.u.i.items.ItemUIRegistryImpl] - Cannot retrieve item agFenster for widget org.openhab.model.sitemap.Text
2015-11-18 21:23:28.960 [ERROR] [o.u.i.items.ItemUIRegistryImpl] - Cannot retrieve item agFenster for widget org.openhab.model.sitemap.Text
2015-11-18 21:23:28.961 [ERROR] [o.u.i.items.ItemUIRegistryImpl] - Cannot retrieve item agFenster for widget org.openhab.model.sitemap.Text

Also once the gDashboard group is added to the active group my item below that config is gone. When Dashing requests the status of that item, I receive the error message:

2015-11-18 21:32:24.701 [INFO ] [o.i.r.i.resources.ItemResource] - Received HTTP GET request at 'items/haus_presence' for the unknown item 'haus_presence'.

In fact it looks like a bug/missing feature in OH to be able to include active groups into other groups.
To work around that it should be possible that Dashing pulls the data out of OH once a minute or so.
Is that done in the jobs/openhab.rb file?
Thanks for your help.
Seb

I just started with dashing. My first “site” is a little status display for the living room.I never heart “coffee-script” and “scss” before. So I’m very interested in examples for widgets, scripts and so on.My biggest success is the temperatur of the bath room.I want to avoid cold temperatures for too long ventilate. So i change the color of the digits. Lower the 20°C the color is red, above the digits are green. You see, I’m an realy beginner.

@waitz_sebastian - I’m not quite sure what you mean here. For example, I have group that covers all my living room ceiling lights (spots, diffused + led lighting), defined as follows:

Group:Switch:OR(ON,OFF) GF_Living_Ceiling "Living Room Ceiling Lights" (gGF,gLivingRoom,gDashboard)

This group is there on my dashboard as a widget with on/off functionality. Seems to work fine. I can use this widget to turn on or off all the items within this group. I have many such nested groups, all working without any issues. Is it possibly the way you’ve got your groups defined? Also the error messages you’ve shown above seem to be an issue with your sitemap and not core openHAB per se. The Dashing rule should still work fine. Can you share both your items definition and the relevant part of your sitemap? That may help shed some light.

(BTW, the dashing side is NOT polling OH. Instead, OH has a rule which is triggered whenever an item belonging to gDashboard group has a state change. But yes, you could do polling by creating a job in the jobs folder of dashing.).

@Frank_Reeth All the widgets that we are using are in the widgets folder that you should have copied across to your server. If you look at the widget folders where the folder name starts with “Oh”, you will find the openHAB specific widgets. Each widget will have its own coffeescript/scss/html file. If you go through these, hopefully you will get a good idea of how it all works.

Hey @smar,
you’re absolutly right. I added the group membership in the wrong order. After doing correctly, the error messages are gone.
My item looks like this:

Group:Switch:OR(ON, OFF) agLichter "Alle brennenden Lichter [(%d)]" <switch> (gDashboard)

I think we’re using the same active group but trying to achieve different jobs. You’re sending a command from dashboard towards OH to control the lights.
I’m trying the reversed. The number of light up lights should be displayed on the dashboard. So OH needs to push towards Dashboard.

Would you mind doing me a favor?
Can you try turning off all your lights via OH UI, and then check if the active group on dashboard also switched? This would confirm, that OH sends towards active group info towards Dashing. But I think this still does not imply that every single OFF will change the status of the active group and thus not trigger the rule to update the dashboard. When enabling debugging in the OH dashboard rule I didnt saw any rule triggering when the active group receives an update.

The more I think about it the scenario an active group might not be the best solution for my use case. Anyone an idea how to display the ammount of burning lights on Dashboard? Same would apply for ammount of open windows.
Thanks much.

UPDATE:
Writing the above text got me thinking. At the end I went away from the active group but defined my own Number item and wrote a small rule that properly counts the items.
items:

Group gLichter
Number haus_brennende_lichter “Alle Brennenden Lichter [%.0f]” (gDashboard) `

rule:

rule “Update QTY of burning lights”
when
Item gLichter received update
then
postUpdate(haus_brennende_lichter, gLichter.allMembers.filter(licht | licht.state == ON).size)
end

This works like charm and the ammount of burning lights as well as ammount of open windows is properly displayed in Dashboard.
Thanks much for talking about my issue.

Hi @waitz_sebastian

Just tried and yes, the dashboard updates correctly even when the group state is changed directly through OH. I’m not sure why you’re not seeing the rule trigger - I have it triggering for all relevant changes, regardless of whether they are items or groups. May be recheck the rule trigger against the original repo?

I also have a widget for my heating system status, which has two values - one for current room temperature, and one for the target temperature. Both of these numbers are displayed on a single widget. The data is pushed from openHAB to the dashboard via the same rule (they have their own group in openHAB). I suspect that something isn’t quite right at your end, but at least you have a working solution!

Hi, this project is awsome. I’m struggling with weather widget as it is NOT being updated. I found in dashing logs constantly the following error:

================================================================================
scheduler caught exception:
undefined method each' for nil:NilClass /home/owca/openhab/src/tmp/openhab-dashboard/lib/ohapp.rb:65:inrefreshWeather’
/home/owca/openhab/src/tmp/openhab-dashboard/jobs/openhab.rb:18:in block in <top (required)>' /home/owca/.gem/ruby/2.0.0/gems/rufus-scheduler-2.0.24/lib/rufus/sc/jobs.rb:230:incall’
/home/owca/.gem/ruby/2.0.0/gems/rufus-scheduler-2.0.24/lib/rufus/sc/jobs.rb:230:in trigger_block' /home/owca/.gem/ruby/2.0.0/gems/rufus-scheduler-2.0.24/lib/rufus/sc/jobs.rb:204:inblock in trigger’
/home/owca/.gem/ruby/2.0.0/gems/rufus-scheduler-2.0.24/lib/rufus/sc/scheduler.rb:430:in call' /home/owca/.gem/ruby/2.0.0/gems/rufus-scheduler-2.0.24/lib/rufus/sc/scheduler.rb:430:inblock in trigger_job’

Why we use some scheduler but not same updating way as for instance “Text” widget? It can collect values from openhab but ohweather widget gets some problems.
I didn’t modify anything in that rb file apart from openhab details.

Actually I found source of the problem. There were no members in json answer. I ran REST query and didn’t get valid output. Because of that got undefined method each’ for nil:NilClass.

In items file I didn’t have valid group definition. Some elements that use MQTT needs (Group) in front of, not after mqtt definition of action…

hi all,

after installing dashing do i have to create a new dashboard with “dashing new dashboard”, bundle that and THEN copy the dashboard repository to /opt/dashboard? the dashboard i created before is in another directory, so should i copy everything from opt/dashboard to that directory?

i am confused…

thx,
stefan