I used to use a version of this back in the SmartThings days, great to see it here at Home Assistant.
One feature I’m wondering about…what do you think about making a “popup” modal for an input_select? So when you tap on the Hainputselect module, a modal menu would appear with the different choices, and tapping one would change the input_select? Seems like this would allow a more efficient use of space, so you don’t have to use tiles to present all the different options for an input_select.
Glad to see you over here 
It’s certainly doable but might be more than my meager HTML skills can handle - I’ll add it to the list.
I’m trying to add a new widget (similar to Hamotion, but more generic “Habinary” that will show any icons for on/off instead of assuming it’s a motion sensor), but I can’t get it to show up in my dashboard. I created an Habinary folder in widgets and the appropriate files, but in my main.erb when I try and use it nothing shows up – and there’s no errors in the JS console or in the server terminal. I have restarted the server.
Is there something else I have to do to make a widget “enabled”?
Did you change the widget names appropriately ib the .coffee and .css files?
Yes sorry I should have been more specific. I changed all the file names, the class name within the .coffee file, etc. I could not get the widgets to show up. After more troubleshooting, I think I was having a very weird issue with Docker. Sometimes file changes I would make were not getting reflected inside the container – so my code editor, editing files that are mounted as volumes inside the Docker container, was having no effect. It was like some weird caching thing – if I blew away the container and remade it, the files would show the latest revisions.
That was the last straw for me with Docker (I also spent 4 hours yesterday fighting Docker’s crappy port forwarding on Mac), so I just abandoned Docker on my dev machine and am running Dashing directly on OS X. Still using the Docker container on my Pi (production).
Any idea why hapush would be picking up some events from HA and not others?
I have no problem with some input_booleans, for example, I can toggle those in HA dev console and the new states show up fine in HADashboard (and the hapush console log).
However, for my new habinary widget, hapush isn’t picking up the changes. For example, I set binary_sensor.garage_double_bay to “off” using the dev console in HA, and nothing shows in hapush. If I manually refresh the dashboard, the new state shows up fine.
Here’s my habinary.coffee, not sure if relevant:
class Dashing.Habinary extends Dashing.Widget
constructor: ->
super
@queryState()
@accessor 'state',
get: -> @_state ? "off"
set: (key, value) -> @_state = value
@accessor 'icon',
get: -> if @['icon'] then @['icon'] else
if @get('state') == 'on' then @get('iconon') else @get('iconoff')
set: Batman.Property.defaultAccessor.set
@accessor 'iconon',
get: -> @['iconon'] ? 'circle'
set: Batman.Property.defaultAccessor.set
@accessor 'iconoff',
get: -> @['iconoff'] ? 'circle-o'
set: Batman.Property.defaultAccessor.set
@accessor 'icon-style', ->
if @get('state') == 'on' then 'binary-icon-on' else 'binary-icon-off'
queryState: ->
$.get '/homeassistant/motion',
widgetId: @get('id')
(data) =>
json = JSON.parse data
@set 'state', json.state
ready: ->
# This is fired when the widget is done being rendered
if @get('bgcolor')
$(@node).css("background-color", @get('bgcolor'))
else
$(@node).css("background-color", "#444")
And the hapush console log, showing a successful input_boolean push but absolutely nothing for my binary_sensor:
(venv) ➜ hapush git:(development) ✗ python3 hapush.py hapush.cfg
2016-10-06 16:36:12,323 INFO Reading dashboard: /Users/mrogers/Projects/hadashboard/dashboards/example.erb
2016-10-06 16:36:12,324 INFO Reading dashboard: /Users/mrogers/Projects/hadashboard/dashboards/main.erb
2016-10-06 16:50:57,611 INFO input_boolean.guests -> on
2016-10-06 16:51:00,325 INFO input_boolean.guests -> off
HAPush is dependent upon the widgets it reads form the erb file - if you added a new widget you will also need to make some edits to HAPush.
BTW, if you find your new widget useful I am happy to take a PR for it!
Ah! Hadn’t found that dependency. Added to the hapush.py file, it’s working now.
And yes, absolutely…I’m going to test it some more, clean it up, and submit it as a more generic binary sensor widget!
Loving it
I feel like there might need to be an “official” way for users to incorporate custom CSS that won’t result in conflicts if they pull down newer builds from master. Currently, you can tweak each module’s SCSS file all day long, but then if a new release comes out that changes the “defaults” you’re going to be dealing with conflicts.
I was thinking of two options:
In either case, the files would be ignored from the repo.
Option 2 I think is cleaner for users. It would also make it easier to do page-level CSS or global overrides, as opposed to only offering the option of targeting each widget.
Thoughts?
Like this idea! (And looking forward to playing with the new widget!)
The PR for the new generic binary widget is open.
As for the CSS customizations…I’m starting to dig into it. I’m probably going to suggest changing nearly all of the widgets’ CSS and coffee files, because there are hardcoded colors in a LOT of places. Still working through it, but I’m thinking about either eliminating most hardcoded colors in each widget’s CSS file (and just allowing them to inherit from more generalized classes like .widget) OR making better use of SCSS variables. So if I take the first route, we’d wipe out stuff like this:
.widget-change-page {
background-color: #444;
.title {
color: #fff;
}
...
…if it matches the “default” settings declared in application.scss (or customize.scss). Things like background color and title color would only be declared in an individual widget’s SCSS file if for some reason we want it to be different than the defaults.
There’s also hard-coded colors within most of the coffeescript files for things like background, I’m not really sure why:
ready: ->
if @get('bgcolor')
$(@node).css("background-color", @get('bgcolor'))
else
$(@node).css("background-color", "#444")
I’m looking at potentially eliminating the default here, so that CSS can be respected (but still overridden if you explicitly declare bgcolor as a parameter on the widget HTML):
ready: ->
if @get('bgcolor')
$(@node).css("background-color", @get('bgcolor'))
Maybe look into creating widget sub classes? This way any attribute unique to that widget would be in it’s own class as an override and anything common would be part of the overall class declaration?
Yeah that’s essentially what I’m saying. All the widgets do have subclasses right now, but the problem is the same CSS is being replicated in most of them. Like the background and title colors. So then if you change the broader-scope styles, they have no effect.
For example, every single widget subclass I’ve looked at (.widget-hagarage, .widget-change-page, .widget-hagroup, etc) has a declaration for the background color, and they’re all the same:
background-color: #444
That’s making customizing them a pain in the ass. That needs to be eliminated, and inherited from a broad-scope .widget, and only overridden in the per-widget classes when necessary.
OK I had a lot of free time this afternoon, so I did a big refactor of the CSS. Here’s the branch; could someone pull it down and help me test? It looks like it works on my dashboard and the example, but I touched so many things I’d appreciate some other eyeballs.
In short:
EDIT: Customization instructions changed. See later post in this thread.
Wow, sorry I am late to the conversation here, I have been travelling.
I’ll take a look over the code this weekend but I like the sound of what you have done a lot Most of what I have done with the coffescript was to take the original from the SmartThings version that FlorianZ created and make minimal changes to support what I was doing on the backend - the backend was really the bulk of the work as things were a little different to SmartThings.
I have made some incremental changes and added some features like optional background colors but wanted to keep the defaults the same, hence some of the fallbacks you saw, which were quick fixes.
I can get by in coffescript and scss but it looks like you have a much deeper knowledge of this stuff than I do so I am happy to take your help
I have your first PR, I’ll take a look and merge over the weekend and I am also looking forward to seeing what you have done with the css refactor - thanks!
Thanks! Glad to contribute any way I can – front-end is more my area of expertise, yes.
Didn’t mean to imply any fault in my previous comments, just making observations to try to explain why I was taking the approach I did. Hope you didn’t take offense. Safe travels.
Quite the opposite - I am glad you are willing and able to help 
I have 2 separate dashboards, one for a tablet and one for mobile. Both are working great, but on the mobile dashboard I have to zoom in for it to fit the screen. Is there a way to have the mobile dashboard autosize to the screen?
Example:
Hello,
Trying to make new weather widget based on wunderground. I copied the haweather folder and files, updated the class in the .coffee file, updated the .erb with Haweatherunderground but just get a blank spot on the dashboard. I found the homeassistant.rb section that gets the data but figured if still pulling the forecast.io data it should display in the new widget. Am I missing a weather specific function somewhere else?
Thanks,
lordsiris
