I’ve been using this on two wall-mounted tablets for a while and wanted a way to blank them when I’m not home or asleep to reduce burn-in and save a bit of power. I couldn’t find a way to blank the dashboard but it’s fairly easy to blank widgets so I wrote a script to do this and linked it to an item which I can call via the exec binding.
The widgets just need a small tweak to their .coffee file to add this:
onData: (data) ->
if @get('visible') == 'ON'
$(@node).fadeIn()
if @get('visible') == 'OFF'
$(@node).fadeOut()
A simple shell script can then turn the widgets on or off:
for widget in $WIDGETS
do
curl -d '{ "auth_token": "secret", "visible": "OFF"}' "$DASH_URL/$widget"
done
Add a rule to turn the tablet dashboards on/off when required.
You can use tasker and motion sensor apps on Android to turn the screen of completely. and then back on when you are in front of the tablet. There should be some notes on this in the Readme file on the github.
Hi, I’m trying to get data from Ruter.no using your example but I have trouble with JSONPATH. Is your config still working? Are you on OH2 with JSONPAT 2.0.0 transformation?
Hi Vegar. It worked well when I was using it under OH 1. But since that, I have upgraded my system to OH 2 and switched to using habpanel. To lessen myself of the painful exercise of implementing this all over again, I have gone for the next best thing which is an iframe wiith ruter.no real time widget on habpanel. This works very well, so I recommend you to check it out: https://ruter.no/iframe-realtime.html
Hi, thanks, nice tip and also a nice design as many web-page implementations in habpanel area not that nice. I’m working on some ruler to split the json return from ruter.no into multiple items to also be able to present it in basic UI and habDroid and will share it when/if solved.
Huge kudos @smar for sharing your original work that was forked from smartthings; its making it easier to get buy off from the wife to automate things!
I wanted to share what I have designed for my house, I can supply more info if someone is interested in adapting it to their needs.
The Living Room Roku is a simple http call, it will report which streaming service app is in use (Roku is the main home screen).
The two “home” panels I modified a Ohpresence widget that I found somewhere, what I like about it is that it won’t change the state like the Ohswitch widget does.
The final note I have for the Play/Pause Roku (its the same api keypress, blame Roku) it kicks off an OS script to send a curl post command to pause or unpause the Roku (useful for lunch/dinner) helps to know if its in an app or on the main screen; which is why the Living Room Roku widget is useful.
–> to be continued in the next post, new user and all and only allowed to post 1 screenshot.
I named the png file to match the channel ID of the Roku app. All of these widgets are also virtual/dummy switches, for some reason OpenHab would double http post commands to the Roku (again a Roku problem as it doesn’t understand ON/OFF). I went through the pain of setting up individual rules for each widget/switch, will probably revisit on a rainy day to setup a smarter way to make the OS curl calls.
This sub page was meant to be more informational, the wife however brought to my attention she wanted buttons to change the hvac modes. So the 4 widgets on the left side are mapped to virtual/dummy switches for rules to watch and update the actual hvac_mode item.
Final sub page is still a work in progress and meant for overrides or scene enforcement. Override Away will force presence in OpenHab for a house sitter, and the morning lights are for nights where I might be have a coughing fit and sleep in the living room…nothing like waking up early due to OpenHab doing exactly what you conifugred it to do.
Hi Smar, thanks for this wonderful post. I was trying to use the Smashing/Dashing dashboard with OpenHAB MQTT service. I have the OpenHAB running on a raspberry Pi and it is also working as an MQTT server. And I have few ESP8266 based wireless devices subscribes and publishes to topics with the MQTT server. So with this setup I am able to control the devices using the OpenHAB App from by phone. Now I was trying to use the nice dashboard (Dashing/Smashing) on my tablet and wanted to control the devices. I found your example in the below link which works with Dashing + OpenHAB + REST API. So I was wondering if there is a way to try MQTT combination instead of REST ? Really appreciate your help and suggestion. Kindly let me know if you need more details about what I am trying to do.
I haven’t looked at the dashing code in some time, but it should be possible to change to an mqtt based implementation. You will need to install ruby based mqtt gems, e.g. https://github.com/njh/ruby-mqtt and then update:
the getState and sendCommand functions in the lib/ohapp.rb file
the replace the SSE client (i.e. the oh2dashing.rb) with an mqtt based equivalent, that subscribes to changes on the mqtt thread and posts to dashing.
Hey Smar, that was a great suggestion . I got it to work from the dashing UI with Openhab running on the Pi. I am able to control the devices now. I had another question though. As I mentioned earlier I have the OpenHAB app already working on my smartphone, from which I can control the devices too. But the problem looks to be is when I change the device status from the App it is not getting updated in the Dashing Dashboard on the tablet. If I do a refresh again on the browser then it shows the updated status. So I was wondering if we can do an autorefresh whenever the device changes its status. Thanks for your help.
T[quote=“nbibin001, post:429, topic:2329”]
when I change the device status from the App it is not getting updated in the Dashing Dashboard on the tablet
[/quote]
Sounds as if your mqtt client isn’t set up correctly (point 2 in my previous email).
Hi Smar, I was also trying to connect an IP camera also into the dashing dashboard as per your example. I have a V380 IP Camera and I was trying to edit the cameras.erb file under jobs folder.
So I was trying to find out how I should be filling these entries in the cameras.erb file. Could you please help me with this as well ?
camera1Host = “cctv_server” ## I guess this should be the IP address of my IP camera. Need a confirmation
camera1Port = “80” ## Not sure what this should be, please help
camera1Username = ‘None’ ## IP Camera’s username from the setup
camera1Password = ‘’ ## IP Camera’s password from the setup
camera1URL = “/mobile/channel01.jpg” ## Not sure what this should be, please help
newFile1 = “assets/images/cameras/snapshot1_new.jpeg” ##This is the folder inside dashing project folder
oldFile1 = “assets/images/cameras/snapshot1_old.jpeg”
This is the port of your camera web server. It is the number that you sometimes see in the url (e.g. http://cam1:8080/img - in this example the port would be 8080). If you don’t see such a number in your url, you are using the default web server port 80.
This is any part in your camera’s web url after domain and port, e.g. if your url is http://camera_ip:port/some_text/other_text, then this part would be /some_text/other_text
Thanks Samar. I figured out the camera URL and is working now. One other question , not sure if you have seen this or not. So I was using a dashing Ohswitch widget to turn on and off a device through the Openhab. The device is working, but the feedback status on the dashing UI seems to be not right. Lets say the initial status of the device is OFF, and when I press the push button on the dashing UI to turn it ON, the device turns on, but the dashing UI button status goes to green for a glimpse of a second and then comes back to the OFF state. The actual device is still ON. I have to actually touch the dashing UI button again to make the status of the UI button to be ON.I was just trying to figure out what might be wrong. The same problem does not occur with the Ohdimmer widget. When I touch the +/- buttons it sets the corresponding status to the device an also the UI shows the right %.
No, I haven’t seen this as it is working fine on my system. You will need to debug and see what messages are being sent to the dashing UI as it sounds as if something is telling dashing to turn off the button. Maybe have a look at the SSE server component, and trace there?
Hey thanks a lot Smar for the pointer. I think I figured it out. It was like my device eventhough it was just doing ON/OFF it was sending status 0 and 100 for it to OpenHAB also to the Dashing. I looked the Dashing code, it was not setup to handling 0/100 for the switches. So I made the changes in my device code to send ON, OFF the dashing UI status changes properly. Works great now…
I am trying to do the next step in the Github dashing link, which is auto load the dashing UI when motion is detected with Tasker and Motion Detector Apps. I couldnt get the detaild instructions though. Do you by any chance have the instructions or any link ? Appreciate your help on this as well.
The only instructions are those on the github. What specifically are you getting stuck with? The way this works is:
Motion Detector (seperate stand alone app from the Play Store) detects motion and sends a trigger to Tasker
Tasker has a profile that listens for triggers from Motion Detector. As soon as it receives a motion detected trigger, it turns the screen on and shows the dash ui.
The profile for Tasker is included in the github, so you won’t need to write it yourself - just import the profile into Tasker.
, not sure if you have seen this or not. So I was using a dashing Ohswitch widget to turn on and off a device through the Openhab. The device is working, but the feedback status on the dashing UI seems to be not right. Lets say the initial status of the device is OFF, and when I press the push button on the dashing UI to turn it ON, the device turns on, but the dashing UI button status goes to green for a glimpse of a second and then comes back to the OFF state. The actual device is still ON. I have to actually touch the dashing UI button again to make the status of the UI button to be ON.I was just trying to figure out what might be wrong. The same problem does not occur with the Ohdimmer widget. When I touch the +/- buttons it sets the corresponding status to the device an also the UI shows the right %.