yeah, was trying to modify the body tag, just wasn’t getting the image to load through docker. Straightened out now.
2 Likes
You have step in ha set to 1 and you have increment at 0.5 that gives the problem that your widget not always can show a value because you feed ha the wrong information.
Hello HAD users!
I have been exploring HA for about a month now and HAD v2 Beta for maybe 2-3 hours. Installation instructions were a breeze (RPi3), and I thank everyone that has contributed!
My first hurdle seems to be with lights. I have a few PHue lights, and when I turn them on from my Dashboard, they come up to 50% brightness (127). When I try to turn on some WeMo switches, that have dumb lights plugged in, I receive errors in my HA log:
Invalid service data for switch.turn_on: extra keys not allowed @ data['brightness']. Got '127'
I am confused as to why everything is only turning on to 50% (127) from the Dashboard. I did not see a setting for this in DASHBOARD.md, and when I turn them on from the HA interface, they turn on to 100%.
Any direction would be greatly appreciated since this means I can not turn on WeMo switches from HAD, and my PHue lights only turn on 50%.
Thanks in advance!
For the 50% issue, use on_level: 255… the on_brightness in the docs doesn’t seem to be working right now.
2 Likes
Lights without the ability to dim should really be switches in widget terms. There is an argument for widgets to set the default on brightness but I am away from my computer at the moment and can’t check it for you
1 Like
A couple observations from me.
You may want to add an “EXPOSE 5050” entry to the Dockerfile. For us docker heads, some proxies namely nginx-proxy will looks for the exposed ports via the container properties to determine if it’s listening. Rather than exposing the port to the outside world using the -p option, allowing the proxy do the work in figuring out where to send upstream is probably ideal.
Any particular reason there are if statements to ensure protocol is http and not https? My reverse proxy sets up letsencrypt for all my web-facing containers so everything automatically gets a virtual host entry behind SSL. Editing a few lines and commenting out the if statement seems to let it run over SSL, but just wondered if this was just a slight oversight in hardcoding some of the logic.
Keep up the good work!
Traceback (most recent call last):
File “/usr/local/bin/appdaemon”, line 11, in
load_entry_point(‘appdaemon==2.0.0b1’, ‘console_scripts’, ‘appdaemon’)()
File “/usr/local/lib/python3.4/site-packages/appdaemon/appdaemon.py”, line 1623, in main
raise ValueError(“Invalid scheme for ‘dash_url’ - only HTTP is supported”)
ValueError: Invalid scheme for ‘dash_url’ - only HTTP is supported
on_level: 255 did the trick for my PHue lights. Thanks for the speedy responses!
Sorry, I should have clarified a little bit more… In HA I have a group defined for each room, with all of the room’s lights. Some rooms have only PHue, some only WeMo, and some a combination of PHue and WeMo. In HA, the WeMo’s are switches while the PHue’s are lights.
I am trying to create widgets in HAD to turn on/off rooms using these groups. The ‘light’ entities are turning on, but the ‘switch’ entities are not turning on, when triggered from HAD. (Triggering the same groups from HA does work.)
1 Like
@aimc any chance you could add textual states to lights, switches, input_boolean, etc for the “icon-impaired” viewers. Like the device tracker widget does. Possibly make it an optional item on the widgets?
Also got kinda thrown for a loop in the custom dashboard.css file when I saw class items with my item names, maybe a comment above those entries to visually separate them from the “global css”?
Also any reason it has to be port 5050, I have “cough” something else in docker that uses that port. I can remap them via docker of course so not a big deal.
Liking what I am seeing so far! Thanks for all your hard work!!
Thanks for the tip, it’s looking much tidier now!
sensor_unit_style: "color: $blue; font-size: 75%"
in the variables.yaml file of my custom_css folder
2 Likes
Thanks for the feedback - to be honest, I didn’t want to sit down and figure out SSL just yet, it was low on my priority list as this is intended to be an internal dashboard kind of thing, however, I know SSL will be a requirement and it was on my list. Allowing an aoutbound SSL connection should also come with at least a basic authorization which is more work that I wanted to defer. I will absolutely get to this and your comments have helped, but it is not a focus for the beta.
Loving this 
1 Like
Ok, I make some assumptions where groups are concerned, they are problematic, I’ll review your info and see what I can figure out.
1 Like
hehe… 5050 I have these on different boxes myself…
It will parse what you have in the dash_url, so make that :5051 or whatever, I believe it should change it.
1 Like
Thanks again. If it can’t be done, it can’t be done, I just wasn’t sure if I was missing something somewhere.
1 Like
J[quote=“lordsiris, post:248, topic:13141”]
@aimc any chance you could add textual states to lights, switches, input_boolean, etc for the “icon-impaired” viewers. Like the device tracker widget does. Possibly make it an optional item on the widgets?
[/quote]
I’ll add it to the list for post beta.
Not sure what you mean by this?
It’s up to you, you configure it in the dash_url parameter.
Thanks!
For the second item I mean that I see class items like “.widget-binary-default-switch-landscape-lights-switch-59-0 .icon-active” in the dashboard.css file in my custom skin. Just wondering if above the compiled entries there could be a comment or seperator or something to break the global css from the compiled. Maybe that still doesn’t make any sense.
thanks, will try it out.
If you are looking i the compiled CSS, your eyeballs will bleed, there is a lot of munging to make it all make sense. What do you expect to gain from looking at that? It’s intended to not be human relevant, it is all derived from the skin, but is processed to make things work.
1 Like
Maybe I’m in docker la-la land again, but i have about 1200 lines of the compiled css in my custom_css/template_name/dashboard.css file. Tomorrow I may just spin up a new VM and install HABeta all by itself…
The compiled CSS shouldn’t be there, it goes into a directory under the config dir called compiled.