I made a custom component for my WattBox, so I can control it along with the rest of my house. Currently it is able to control the switches and monitor all the sensors in the system. There are definitely a few more things I will be working on to make it cleaner but it is functional now. Anyone else have a WattBox to test with?
It is located at https://github.com/eseglem/hass-wattbox please let me know if it works, or needs fixes.
I have two. I’d be happy to test this out. How do I distribute the configuration amongst my yaml files? My are WB-700-IPV-12 IP controlled outlets, not UPS devices.
If you add it into your custom components then use this it should work. Default user/password are wattbox/wattbox on mine at least.
wattbox:
host: x.x.x.x
username: xxx
password: xxx
name: wattbox1/2
resources:
- audible_alarm
- auto_reboot
- cloud_status
- mute
- power_lost
- safe_voltage_status
- current_value
- est_run_time
- power_value
- voltage_value
Also that assumes port 80 (the default) if you changed it, add that as another parameter.
Should work, I removed the resources that shouldn’t exist without the battery. I only have one, so not 100% certain it works for two.
Configured as shown results in:
Error during setup of component wattbox
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/homeassistant/setup.py", line 151, in _async_setup_component
hass, processed_config)
File "/config/custom_components/wattbox/__init__.py", line 87, in async_setup
hass.data[DOMAIN_DATA] = WattBox(host, port, username, password)
File "/config/deps/lib/python3.7/site-packages/pywattbox/wattbox.py", line 59, in __init__
self.has_ups = bool(soup.hasUPS.text)
AttributeError: 'NoneType' object has no attribute 'text'Alright, I see whats happening. I was assuming all the fields in the XML would always exist. I will release a new version of pywattbox tonight that should fix that. Probably need to use getattr instead of just assuming it will exist everywhere.
Ok, try and update it. Put a lot of safety checks into the underlying API that should protect against that happening.
OK. I’ve got both sensor types for all resources listed:
binary_sensor.wattbox100_audible_alarm - off
sensor.wattbox100_current - 1.5
They accurately reflect the related status conditions of the WattBox. Some of these don’t make sense for a outlet strip, but with On/Off control of individual outlets, would be a worthwhile addition.
BTW, No go on multiple hosts.
core-ssh:~# hassio homeassistant check
ok
core-ssh:~# hassio homeassistant check
Error: Testing configuration at /config
ERROR:homeassistant.util.yaml:YAML file /config/configuration.yaml contains duplicate key "host". Check lines 151 and 166.Mine has an UPS so I don’t know what all makes sense or not, was just guessing. I realized after posting it that power_lost makes no sense without a battery, since it will be impossible to report. And est_run_time as well now that I look again. You can add or remove resources as they make sense for you.
It should already have individual controls for each outlet. They should show up as switch.wattbox100_outlet_(1-12) in the dev panel. I was thinking about making them optional, but at this point it should have added 12 automatically based on your hardware version. If it did not, I will add more logging to it to see what is happening. Probably should add more logging no matter what.
I will have to do more research as to how to have multiple of them added then. I know other integrations allow for it, but not sure how.
It has created the switches for the outlets. I missed that. Multiple units in an installation is fairly common. I’ll play around with it some more.
Thanks!
So far, so good. All is working as expected. HA log is on error and nothing related to this has shown up. Looking forward to further testing with multiple hosts.
Thanks again.
Glad its working for you, I haven’t had much time to tweak it this week, but should have some time this weekend. Trying to see about making it async to speed it up, and add a ‘Master Switch’ into it. As well as figure out multiple hosts.
Pushed an update that should allow you to add multiple. It changes the config format just a little, example on git. I only have the one, so I had to add the same one twice, which did work. Hopefully it will work for you as well.
It also added a master switch. Simulates the same action as pushing the power button. Not totally happy with it, and it is a bit slow, but it does work. Think when I make it all async it will work faster. Right now it takes its status from the other outlets, so if you turn one of them on, it is considered on. Which means hitting it will turn off. And I could see it as being desirable to turn on all of them instead. The switch does have the turn on and turn off actions, which I think you can still trigger no mater the status though. But the normal switch components are not really understanding of that.
Multiple hosts is not quite there. The master switch following the normal switch status creates unusual behavior. On one wattbox I have two open sockets. If I turn either or both off, the master switch and corresponding sockets and master switch on the second host also move to off. The actual status remains on, but switch indicates off. This works the other way as well. Turn host1/sw7 off, host2/sw7 moves to off. Sensor status on the States page shows off, but outlet 7 on both hosts remains on. These linkages are reflected across similarly numbered switches. As an example, If host1, outlet 12 is switched off and host2 outlet is on, host1 outlet indicator is forced back to on.
I get all the sensors even though they weren’t defined in configuration.yaml.
wattbox:
- host: !secret wattbox100_ip
username: !secret it_user
password: !secret it_psswd
name: wattbox100
- host: !secret wattbox101_ip
username: !secret it_user
password: !secret it_psswd
name: wattbox101
resources:
- current_value
- power_value
- voltage_valueI was afraid it wasn’t going to work right. I only have one, so I added it twice. The switches were sort of synced for me, but I expected that. When I flip host1/sw7 it actually turns on, then 30 sec later when the whole thing updates host2/sw7 flips on. And vice versa. Both of which are actually affecting the host.
For the first one, because resources was not defined, it defaults to all of them. But the second one should only have the three. Do they both have all of them? Thats odd, seems like it didn’t actually add the two, and under the hood its only one.
Actually, what version of HA are you running? I only tested the new changes on 0.91.1 so that could be a problem. Would also suggest, if you haven’t already, delete the whole folder replace it with the latest code from github. Just in case.
I might have to make a branch with excessive logging and have you run that one if another review on my part can’t find anything obvious.
Specifying resources for host1 eliminated the unwanted sensors. As you said. I’m running HA 0.91.0, HassOS 2.11. I’ll refresh the wattbox directory, move to 0.91.1, and let you know if that improves host segregation.
UPDATE: HA 0.91.1, wattbox code refreshed. Hosts still linked.
Really just saving this for later. I’m just starting to set up my HA installation and I have a few wattbox units I’ll be looking to incorporate with it.
@GaryK Finally got a chance to poke at this a bit more. Still not sure whats up. Can you add some logging to it?
_LOGGER.debug(', '.join([str(v) for k,v in hass.data[DOMAIN_DATA].items()]))
_LOGGER.debug(repr(hass.data[DOMAIN_DATA]))
Would go on line 100 of init.py right be for the return.
And then ensure logging is on for debug of the component. Something like this.
logger:
default: info
logs:
custom_components.wattbox: debug
You should end up with something like this:
2019-04-20 09:03:54 DEBUG (MainThread) [custom_components.wattbox] Wattbox (http://192.168.1.100:80): WB-700CH-IPV-12, Wattbox (http://192.168.1.101:80): WB-700CH-IPV-12
2019-04-20 09:03:54 DEBUG (MainThread) [custom_components.wattbox] {'wattbox1': <pywattbox.wattbox.WattBox object at 0x7efe40236400>, 'wattbox2': <pywattbox.wattbox.WattBox object at 0x7efe40231be0>}
Where they both should have separate IPs and different memory locations? The behavior you are describing seems like its only got one memory location, somehow. Kind of at a loss at this point.
@flippedcracker Let me know if there is anything I can do to improve. I only have the 1, and it has a battery. So kinda just shooting from the hip for multiple and no battery. Contributions also welcome, if you have improvements.
Here’s what I got:
-------------------------------------------------------------------
wattbox
Version: 0.1.1
This is a custom component
If you have any issues with this you need to open an issue here:
https://github.com/eseglem/hass-wattbox/issues
-------------------------------------------------------------------
2019-04-21 04:25:58 DEBUG (MainThread) [custom_components.wattbox] Wattbox (http://ip:port): WB-700-IPV-12
2019-04-21 04:25:58 DEBUG (MainThread) [custom_components.wattbox] {'wattbox100': <pywattbox.wattbox.WattBox object at 0x7f8359215400>}
2019-04-21 04:25:58 DEBUG (MainThread) [custom_components.wattbox] Wattbox (http://ip:port): WB-700-IPV-12, Wattbox (http://ip:port): WB-700-IPV-12
2019-04-21 04:25:58 DEBUG (MainThread) [custom_components.wattbox] {'wattbox100': <pywattbox.wattbox.WattBox object at 0x7f8359215400>, 'wattbox101': <pywattbox.wattbox.WattBox object at 0x7f8357f82208>}That is so weird. They are clearly different IPs, and different locations in memory. At a bit of a loss for how they might be behaving in the way they are. If you only add one, does it work right? And then if you swap which one you add, that as well?
When there is only 1, switches work correctly.