Drayton Wiser Home Assistant Integration

Awesome, will merge in…

Damm , gonna have to make a Release 1.9.1…

I’ll wait to hear if there are any other issues…

Hi @Angelo_Santagata I am very confused, I am new to this so am probably doing something dumb… any advice appreciated. 1.9 rocks btw.
I have set up several automations for controlling the heating triggered by iPhone actions but one I just cannot get to work. It is using the wiser.boost_heating service.
The service runs ok when I run it with the same data in the developer tools and the iPhone message is sent so it seems to fail when I call the service as an action in the automation. Other services work in very similar automations (turning HW on/off, turning heating on in a room etc.).
Thanks in advance. Here is the except from automations.yaml:

- id: '1582988347353'
  alias: Heating Emilys Room Boost
  description: ''
  trigger:
  - event_data:
      actionName: EmHeatBoost
    event_type: ios.action_fired
    platform: event
  condition:
  - condition: zone
    entity_id: device_tracker.emilys_iphone
    zone: zone.home
  action:
  - data:
      message: Emily's heating boosted to 20 for 1 hr. xx
    service: notify.mobile_app_emilys_iphone
  - data:
      temperature: 20
      time_period: 60
    service: wiser.boost_heating
    entity_id: climate.wiser_egr_bedroom

Hi, please ignore the above, indented the client_id to the same level as the Temperature and time_period and it works…

Awesome, I was out and about this weekend and was just getting around to answer you :slight_smile:

Hi Angelo, great work BTW!
I’m probably missing something, but can I set Wiser to Away using automation? I can turn the heating off using climate, but I don’t see a way to set it to Away

Thanks

1 Like

Great work. Am new to hassio and have been slowly installing on a fresh centos 8 install - so far so good. Re the issue with no plugs, would this also throw a wobbler if there is not hot water switch too ?
I too had had issues but did a 2.0 install this morning and see wiser heat hub in integrations but when I click configure it just hangs ?

Recommend using the 1.9 release at the moment, looks like wiser have updated the hubs and broken the install/config flow procedure…

Excellent thanks. I had tried using (what I thought was) 1.9 and had errors, swapped for 1.9dev and have a working system ! (I have no smart switches - just using wiser with trv in a 1 channel system).

Right , we’ve fixed the issue, and ive released R2.1_beta1 through HACS… Should be ok now…

dont have hacs but have tried the git location https://github.com/asantaga/wiserHomeAssistantPlatform/tree/master
master says last updated 4 hours ago, and also r2.1_beta1 and r2.1_release_candidate but with older updates
All hang on the ‘configure’ button on the integrations page.
using the master from the url above as the best guess I see the following on load

CGroup: /system.slice/home-assistant.service
├─7608 /srv/homeassistant/bin/python3 /srv/homeassistant/bin/hass -c /home/homeassistant/.homeassistant
└─7618 /srv/homeassistant/bin/python3 -m pip install --quiet wiser-heating-api>=1.0.7.2 --upgrade --constraint /srv/homeassistant/lib64/python3.6/site-packages/homeassistant/package_constraints.txt

All looks good as update
however when i click configure and get the hand I see

Mar 31 14:38:09 centos8. hass[7608]: return await handler(request)
Mar 31 14:38:09 centos8. hass[7608]: File “/srv/homeassistant/lib64/python3.6/site-packages/homeassistant/components/http/view.py”, line 123, in handle
Mar 31 14:38:09 centos8. hass[7608]: result = await result
Mar 31 14:38:09 centos8. hass[7608]: File “/srv/homeassistant/lib64/python3.6/site-packages/homeassistant/components/config/config_entries.py”, line 154, in get
Mar 31 14:38:09 centos8. hass[7608]: return await super().get(request, flow_id)
Mar 31 14:38:09 centos8. hass[7608]: File “/srv/homeassistant/lib64/python3.6/site-packages/homeassistant/helpers/data_entry_flow.py”, line 78, in get
Mar 31 14:38:09 centos8. hass[7608]: result = await self._flow_mgr.async_configure(flow_id)
Mar 31 14:38:09 centos8. hass[7608]: File “/srv/homeassistant/lib64/python3.6/site-packages/homeassistant/data_entry_flow.py”, line 86, in async_configure
Mar 31 14:38:09 centos8. hass[7608]: if cur_step.get(“data_schema”) is not None and user_input is not None:
Mar 31 14:38:09 centos8. hass[7608]: AttributeError: ‘NoneType’ object has no attribute ‘get’

I suggest your install HACS - it is THE way that community components are getting released nowadays. Makes your life easier, makes the component developer’s life easier.

Hey , I agree with John, HACS is the way to go.

The master is actually at 2.1beta2, (Just noticed the readme is wrong).

But I’ll admit im not 100% sure whats going wrong…

Are you on the latest HACS? I only ask as I see in the above home assistant log that it seams to be using python3.6… AFAIK that isnt supported anymore… maybe that the issue?

No as it is a reasonably fresh Centos 8 install I have a fair few issues adding what i want / need into it. One of them was HACS so I found (ab)using the git site worked so I have done that so far. I know 3.6 may be an issue in the future but is another item on the growing list of things to address!

I wonder if this is a python3.6 issue. The line above

Mar 31 14:38:09 centos8. hass[7608]: if cur_step.get(“data_schema”) is not None and user_input is not None:
Mar 31 14:38:09 centos8. hass[7608]: AttributeError: ‘NoneType’ object has no attribute ‘get’

Is not from my code and this appears to be in HA itself, the new integration uses config flow so that might be the issue…

you could try 1.9 instead , it doesnt use config flow…

Alternatively have you tried docker? thats what I use for Home Assistant and it works fab…

tried 2.1 beta 2 and had same issue so have now reverted back to 1.9dev which seems to work fine.

Hi Angelo

Just updated to 2.1 from 1.9 and got a missing sensor, a few new ones and a few errors.

  1. My smartplug sensor has disappeared. it was of the form sensor.wiser_smartplug_xxxxxxxxxxx. I cannot find it in dev / states and I only know about it as I had it in Glance card so I could see the zigbee signal strength, now in its place is a warning icon.

  2. Whilst looking for the smartplug sensor, I see we have battery sensor now for the TRV’s, I didn’t see this mentioned in the change log and the readme. I only mention this because…

  3. I have a lot of recurring errors which I believe are being caused because the battery_voltage attribute of the TRV sensor is not there anymore. I have an automation that checks the voltage status and templates embedded in the glance card that show the signal strength of the TRV’s which render them red if the battery voltage goes below the magic 26 number.

So, is the loss of the smartplug sensor and the battery_voltage attribute by design or an ommission? Just so I know before I go and rewrite my stuff. :slight_smile:

Thanks for the great integration BTW

mmm lots here to see!

  1. I just checked my setup and smartplug sensor and switch are both there … but Ive just noticed its just called sensor.smartplug whereas all the other wiser devices are called ‘sensor.wiser_xxxx’ so I wonder if this is the bug , it got renamed…

Logged a new issue (#88) and fixed it in a new commit in the dev branch.

  1. Yes, added to readme.md in dev, thanks

  2. This is a breaking change, we created the battery sensors and then removed the attributes but forgot this is a breaking change and shouldnt of happened… . Sorry… What Ive done is fixed this one too in the dev branch

Ive created a R2.2.alpha release with these fixes , please let me know if there are any other issues

Hi,

Thanks for the quick fixes.

I have downloaded R2.2.alpha which has fixed the battery_voltage attribute of the trv sensors.

But I am a bit confused, you said your smartplug showed up as sensor.smartplug but mine isn’t.
It shows as sensor.wiser_switch in my setup not as smartplug, (which it did before your alpha fix I notice - doh!).
I have now also lost the switch switch! (switch.wiser_switch which was ok in R2.1)
It now is switch.wiser_wiser_switch

I can change things to accommodate these no problem but will they revert later?

I notice there is a newer sensor.py to fix a battery discrepancy should I download that as well?

Thanks

oh , i’ll look at it again…

you should be able to download 2.2alpha for both fixes unless I screwed that up too…

I’ll look again tonight.

Hi,

Don’t bust a gut on my behalf. I have it working ok with your fix and the changes.
I will need to alter things once you have sorted it to your satisfaction though.

Cheers