mindrustuk / heatmiser-for-home-assistant Goto Github PK

I have 19 heatmiser devices in operation: 9 Neostats, 3 Neostat-E, 5 Neostat-HW and 2 repeaters.
These are all picked up and their json data is visible in my HA log file and all the Neostats are working in HA.
However I notice that only the Neostats and Neostat-E are shown under the Configuration Integration and Entities grouped by "Heatmiser Neo Climate":

The Neostat-HW switches and repeaters are reported as Entities as from the integration Switches:

It would be neat if the reported devices was reported accurately for an at-a-glance check and all entities were shown as being grouped under "Heatmiser Neo". I can see that the integration name is pulled from the manifest.json name field for the climate entities.

According to Appendix B of the NeoHub API docs the INFO command is deprecated.

What is the new way to install on latest home assistant, with manifest.json etcetera?
Keep up the great work!

Hi,

I am having issues setting the preset mode 'away'. When calling the climate.set_preset_mode with preset_mode set to 'away', I am given the following error:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 133, in handle_call_service
    connection.context(msg),
  File "/usr/src/homeassistant/homeassistant/core.py", line 1236, in async_call
    await asyncio.shield(self._execute_service(handler, service_call))
  File "/usr/src/homeassistant/homeassistant/core.py", line 1261, in _execute_service
    await handler.func(service_call)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 213, in handle_service
    self._platforms.values(), func, call, service_name, required_features
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 348, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 370, in _handle_service_platform_call
    await getattr(entity, func)(**data)
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 431, in async_set_preset_mode
    await self.hass.async_add_executor_job(self.set_preset_mode, preset_mode)
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 427, in set_preset_mode
    raise NotImplementedError()
NotImplementedError

According to git log, I am running the latest version.

configuration.yml:

climate:
  - platform: heatmiserneo
    host: <>
    port: <>

The state of one of the thermostats:

hvac_modes:
  - heat
current_temperature: 24.8
min_temp: 7
max_temp: 35
temperature: 16
current_humidity: 0
hvac_action: idle
friendly_name: Living Room
supported_features: 1

Which seems to be missing an 'away_mode' state.

Furthermore, wondering if there are any other preset_modes other than away?

For automatic updates off heatmiserneo, add HACS support?

Brilliant on the new Integration. Thanks.
Is it worth adding a bit to the read.me or Wiki to steer the innocent here?

Also "neo-hub" didn't work for me. I had to add the actual URL. That may be a neohub gen1 issue?

As I understand the installation is:

1. Obtain code for custom component
2. Place in custom_components folder as "heatmiserneo"
3. Configure via UI or via configuration.yml

The current readme implies that steps 1 and 2 above are not required if you are configuring via the UI.

I'm running the latest version of both home assistant and this repo. After around 24 hours the Neohub will 'lock up' by that I mean:

• It leaves my hone network
• It disconnections from the heating controller (no WiFi symbol)
• It no longer appears in the official app
  I don't see any errors in the HASS log that are related.

This is obviously a bug in the Neohub - it shouldn't lock up BUT when the custom component is removed I have no issues and the Neohub never needs to be rebooted.

Any ideas what is happening here?

Is the local API supported by Neohub? Are there any more logs I can collect?

@leaskovski @MindrustUK you may already be aware of this document but said I would let you know.

A UK company NorthBT have a product which interfaces with NeoHub https://www.northbt.com/products

Their reference document might contain some insights which may be useful to you
https://www.northbt.com/doc/driver/HeatmiserNeo%20Driver%20Manual.pdf

Using a neostat in timeclock mode gives some strange results. This issue is really with the Heatmiser API, as the Home Assistant component is just returning the result which the API gives it.

AFAIK the API can return what mode the thermostat is running in, so the irrelevant results could be ignored.

I'm not sure if the HA climate component allows for switching without temperature, or how this could be implemented. (Potentially would have to be a switch component rather than climate)

I'm running Home Assistant on some slow hardware where I'd rather not install HACS.

Just wondered if there were any plans to get this merged in to core, or what remains to be done before this can happen?

I was also curious if the plan would be to replace the existing Heatmiser integration or add an additional one, if your project is specific to the neoStat line of thermostats?

I have a neoStat thermostat and use the Heatmiser Neo iOS app. The current official integration doesn't seem to set up correctly, but looks like your integration would.

The integration with HA was working for me on 7th November.
I don't think the code on my HA updated in line with @leaskovski fork and I have resorted to attempting a reinstall of the Heatmiser Integration.
The instructions in the current readme.md are not working specifically at the point of adding the integration repository.
I'm running Home Assistant core 2012.12.0 on OS 5.8.
The readme.md says:
Step 1: Add to HACS
Open HACS Go to the Settings tab Add "https://github.com/MindrustUK/Heatmiser-for-home-assistant" as a repository as an "Integration" type. Go to the Integrations tab Search for "Heatmiser Neo Integration", select and install

There is no option in HACS to add a repository.
The Heatmiser Integration which used to sit alphabetically in this list isn't there anymore.

Compare this list with my previous screenshot in the readme.md

I have added repositories previously using the Supervisor Add-on function but the URL https://github.com/MindrustUK/Heatmiser-for-home-assistant isn't recognised as a repository, FWIW I would expect the URL to point to a file type *.git

Can anybody advise?

Add support for handling "offline" devices, maybe useful in raising alerts / monitoring.

Attempted to set this up today with this config:

climate:
  - platform: heatmiserneo
    host: 192.168.x.x
    port: 4242

But getting the following errors in Home Assistant (v 0.114.3):

First:

Setup of climate platform heatmiserneo is taking over 10 seconds.

Then:

Error while setting up heatmiserneo platform for climate

Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 184, in _async_setup_platform await asyncio.shield(task) File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run result = self.fn(*self.args, **self.kwargs) File "/config/custom_components/heatmiserneo/climate.py", line 73, in setup_platform for device in NeoHubJson['devices']: TypeError: 'bool' object is not subscriptable

The Neo hub is definately on that IP address, and I haven't found any other similar issues going on, so wondering if its just the Home Assistant version, or an error I've made in install, or perhaps it is a genuine bug?!

Let me know if you need any further info.

As the title suggests 😁

It looks like neostats also show as DEVICE_TYPE = 0

An issue I came across when restarting HA, which I think might be more related to the neohubapi rather than this integration. It looks like there is some timing issue at midnight with 00:XX being passed as 24:XX, see logs below.
After 01:00 it would work again.

_Logger: homeassistant.components.climate
Source: custom_components/heatmiserneo/climate.py:56
Integration: Climate (documentation, issues)
First occurred: 0:37:58 (1 occurrences)
Last logged: 0:37:58
Error while setting up heatmiserneo platform for climate
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 205, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/heatmiserneo/climate.py", line 56, in async_setup_entry
_, devices = await hub.get_live_data()
File "/usr/local/lib/python3.8/site-packages/neohubapi/neohub.py", line 380, in get_live_data
thermostats.append(NeoStat(self, thermostat))
File "/usr/local/lib/python3.8/site-packages/neohubapi/neostat.py", line 98, in init
_time = datetime.strptime(self.time, "%H:%M")
File "/usr/local/lib/python3.8/_strptime.py", line 568, in _strptime_datetime
tt, fraction, gmtoff_fraction = _strptime(data_string, format)
File "/usr/local/lib/python3.8/_strptime.py", line 349, in strptime
raise ValueError("time data %r does not match format %r" %
ValueError: time data '24:00' does not match format '%H:%M'

As well as the climate entities in HA that the are generated automatically, I use Sensors and Switches to display the information in my Lovelace UI.

As I want to compare temperatures in various location I'm using a History Graph to pull all the temperatures together displaying sensor values. My sensor.yaml contains lines like:

• platform: template
  sensors:
  temp_bed_1:
  friendly_name: "Temp Bedroom 1"
  unit_of_measurement: '°C'
  value_template: "{{ state_attr('climate.bedroom_1', 'current_temperature') }}"
  temp_bath_1:
  friendly_name: "Temp Bathroom 1"
  unit_of_measurement: '°C'
  value_template: "{{ state_attr('climate.bathroom_1', 'current_temperature') }}"

It would be really neat if sensor entities were created along with the climate entities.

I'm also using switches to display Heatmisers that are working as timers. My switch.yaml contains lines like:

• platform: template
  switches:
  towel_rail_1:
  friendly_name: "Towel Rail 1"
  value_template: "{% if is_state('climate.towel_rail_1', 'heat') %} on {% else %} off {% endif %}"
  turn_on:
  turn_off:

At the moment this only has the plus point of not displaying 255 temperatures. I don't see how these can be picked out automatically because the JSON {'TIMECLOCK': True} isn't being recorded. These aren't working as intended because the climate entity only has in hvac_modes of 'off' or 'heat'. The state is 'heat' when the neo-stat is not in stand-by and shows regardless of whether or not the neo-stat output is on or off. ( Ironically for temperature controlling neo-stat the output is on when attribute temperature>current_temperature)

In the annotation in comments on the original climate.py @MindrustUK notes

47 # Heatmiser does support all lots more stuff, but only heat for now.
48 #hvac_modes=[HVAC_MODE_HEAT_COOL, HVAC_MODE_COOL, HVAC_MODE_HEAT, HVAC_MODE_OFF]
49 # Heatmiser doesn't really have an off mode - standby is a preset - implement later
50 hvac_modes = [HVAC_MODE_OFF, HVAC_MODE_HEAT]

Consider the Heatmiser Neo-stats here operating as a temperature controllers and comparing HA with the Heatmiser App:

I read this as:
Bathroom 1 is in Standby/Away/Frost mode (grey) and isn't on (idle).
Bathroom 2 is following the "bathrooms" profile (orange) and isn't on as the actual temperature is above the set temperature (idle).
Bedrooms 1 & 2 are following the" bedrooms"(orange) profile and actual temperature is below the set temperature (heating)

So we have four possible outcomes grey/orange plus idle/heating.

The latest climate entity documentation (https://developers.home-assistant.io/docs/core/entity/climate/) identifies built in presets with the option of adding custom presets. The built in presets are:
Name | Description
ECO | Device is running an energy-saving mode
AWAY | Device is in away mode
BOOST | Device turn all valve full up
COMFORT | Device is in comfort mode
HOME | Device is in home mode
SLEEP | Device is prepared for sleep
ACTIVITY | Device is reacting to activity (e.g. movement sensors)

These could be mapped:
grey/idle => AWAY
grey/heating=> ECO
orange/idle => COMFORT
orange/heating => BOOST

I'm not sure how these mappings might work for time clocks. Are they just AWAY or BOOST?
Any views or comments on this?

I added the repository via HACS, installed the integration and restarted Home Assistant, but was then unable to install the integration from the Configuration page - the integration did not appear in the list.

Please see images attached for more detail

Setting "Away" on any thermostat sets all thermostats to away.
Have also found that turning away mode off does not seem to work.
Tracked down the "away on all" to a faulty Json request. Hope to fix this soon.

The neohub advertises itself as a zeroconfig device.

• Support manual addition of hub if mdns is not available
• Do not trust the advertised port on the zerocofig enry
• Use the mdns hostname rather than IP when discovered this way

@mindtrustUK: I hardly dare ask as I know that you don't have much time to work on the .py file, but I do it anyway: I am using lovelace card "simple thermostat" which should show buttons but doesn't

I also have Mitsubishi air conditioners which uses Melcloud (climate.py) and the do show buttons in the same simple thermostat card:

my question is whether it would be possible to add buttons for heatmiserneo?

The Melcloud "states" have the following information:

I guess the "operation mode" and "operation list" does the trick.

Could the applicable options be included in the climate.py file of the Neo?

Originally posted by @Trouble-51 in #3 (comment)

Hi, I am using the original version for 11 thermostats. Any chance of sophisticating the project with more options that are available on the app from Heatmiser?

Not sure how practical this is - but my setup has a number of other sensors for temperature/humidity around the house, and I have to 'double up' in rooms/zones where I have heatmiser neostats. Since they have the ability to tell us temperature, is it practical to expose these to HA as sensor entities as well as climate devices?

While device specific code is very simple in this integration (just TCP and json) it would be best to split it into a seprate library.

In particular this is a Home Assistant rule: https://developers.home-assistant.io/docs/creating_platform_index/

One Home Assistant rule is that the integration should never interface directly with devices. Instead, it should interact with a third-party Python 3 library. This way, Home Assistant can share code with the Python community and keep the project maintainable.

It might be possible to reuse something like https://gitlab.com/virchow-personal/neohubby/ but on the other hand, if we have a few interested people here in this project, creating our own project might be more flexible for us.

CC: @DrTree

trying to continue to use the legacy installing of manually putting it heatmiserneo folder directly into custom_components
but after update it doesnt seem to work anymore :(

i recently updated, first time for many months ! and it now get errors
2021-07-13 11:52:33 ERROR (MainThread) [homeassistant.components.climate] The heatmiserneo platform for the climate integration does not support platform setup. Please remove it from your config.

which i presume wont now be supported, as config is only now via the integration ?

im now using..
Home Assistant 2021.7.1

Hi -- I've been using this integration via hacs for a number of months successfully. I have a neohub with 3 room thermostats (neostat) and a fourth that's acting as a hot water switch.

Earlier today, when I updated the integration, my thermostats were no longer detected. It did, however, detect the hot water switch (which I'm not sure was detected before). I'm happy to do any debugging suggested. The debug logs from the integration are unremarkable:

2021-01-18 21:00:35 INFO (MainThread) [custom_components.heatmiserneo] Adding Switches: [<Entity Hot Water: off>] 
2021-01-18 21:00:35 DEBUG (MainThread) [custom_components.heatmiserneo] Entered update(self)
2021-01-18 21:01:05 DEBUG (MainThread) [custom_components.heatmiserneo] Entered update(self)

I'll try to get youmore debugging info and add to this issue.

NeoPlugs (Device ID 6) show up as a Thermostat in HASS. Change this behavior so they are not presented as a Climate device.

Sorry, opened this with my work account, will resubmit with personal

After upgrading Heatmiser integration to the latest version (with neohubapi being a separate library now) it seems to occasionnaly get "stuck", with status not being updated and commands not being passed to the Neohub.

When this happened, I observed the following symptoms:

1. An "Updating heatmiserneo climate took longer than the scheduled update interval" error message is logged every minute:

Feb  6 11:09:24 lizard hass[9304]: 2021-02-06 11:09:24 WARNING (MainThread) [homeassistant.components.climate] Updating heatmiserneo climate took longer than the scheduled update interval 0:01:00
Feb  6 11:10:24 lizard hass[9304]: 2021-02-06 11:10:24 WARNING (MainThread) [homeassistant.components.climate] Updating heatmiserneo climate took longer than the scheduled update interval 0:01:00
Feb  6 11:11:24 lizard hass[9304]: 2021-02-06 11:11:24 WARNING (MainThread) [homeassistant.components.climate] Updating heatmiserneo climate took longer than the scheduled update interval 0:01:00

2. No network traffic is being sent from Home Assistant to Neohub (checked using tcpdump).
3. netstats shows a few established tcp connections from Home Assistant to the Neohub:

netstat -n | grep 10.11.12.67
tcp        0      0 10.11.12.2:44380        10.11.12.67:4242        ESTABLISHED
tcp        0      0 10.11.12.2:44378        10.11.12.67:4242        ESTABLISHED
tcp        0      0 10.11.12.2:57284        10.11.12.67:4242        TIME_WAIT
tcp        0      0 10.11.12.2:44382        10.11.12.67:4242        ESTABLISHED
tcp        0      0 10.11.12.2:44384        10.11.12.67:4242        ESTABLISHED

4. Stopping homeassistant shows that these TCP connections were not actually active on the Neohub side (it sends back RST in response to FIN):

12:19:02.932468 IP 10.11.12.2.44378 > 10.11.12.67.4242: Flags [F.], seq 999241392, ack 2491317285, win 502, options [nop,nop,TS val 4228902972 ecr 6392437], length 0
12:19:02.932671 IP 10.11.12.2.44380 > 10.11.12.67.4242: Flags [F.], seq 2142873974, ack 1140983017, win 502, options [nop,nop,TS val 4228902972 ecr 6392437], length 0
12:19:02.932740 IP 10.11.12.2.44382 > 10.11.12.67.4242: Flags [F.], seq 3942683128, ack 60268326, win 502, options [nop,nop,TS val 4228902972 ecr 6392437], length 0
12:19:02.932811 IP 10.11.12.2.44384 > 10.11.12.67.4242: Flags [F.], seq 3296834747, ack 1860058818, win 502, options [nop,nop,TS val 4228902972 ecr 6392437], length 0
12:19:02.932807 IP 10.11.12.67.4242 > 10.11.12.2.44378: Flags [R], seq 2491317285, win 0, length 0
12:19:02.932866 IP 10.11.12.67.4242 > 10.11.12.2.44380: Flags [R], seq 1140983017, win 0, length 0
12:19:02.932917 IP 10.11.12.67.4242 > 10.11.12.2.44382: Flags [R], seq 60268326, win 0, length 0
12:19:02.945824 IP 10.11.12.2.44378 > 10.11.12.67.4242: Flags [F.], seq 0, ack 1, win 502, options [nop,nop,TS val 4228902972 ecr 6392437], length 0
12:19:02.945927 IP 10.11.12.2.44380 > 10.11.12.67.4242: Flags [F.], seq 0, ack 1, win 502, options [nop,nop,TS val 4228902972 ecr 6392437], length 0
12:19:02.945989 IP 10.11.12.2.44382 > 10.11.12.67.4242: Flags [F.], seq 0, ack 1, win 502, options [nop,nop,TS val 4228902972 ecr 6392437], length 0
12:19:02.946050 IP 10.11.12.2.44384 > 10.11.12.67.4242: Flags [F.], seq 0, ack 1, win 502, options [nop,nop,TS val 4228902972 ecr 6392437], length 0
12:19:02.946135 IP 10.11.12.67.4242 > 10.11.12.2.44378: Flags [R], seq 2491317285, win 0, length 0
12:19:02.946211 IP 10.11.12.67.4242 > 10.11.12.2.44380: Flags [R], seq 1140983017, win 0, length 0
12:19:02.946384 IP 10.11.12.67.4242 > 10.11.12.2.44382: Flags [R], seq 60268326, win 0, length 0
12:19:02.946417 IP 10.11.12.67.4242 > 10.11.12.2.44384: Flags [R], seq 1860058818, win 0, length 0

5. Neostat itself is working fine when this happens (checked by manually sending a {"INFO": 0} command).

I took a quick look at the neohubapi source code and observed this integration during normal operation, and I believe it is usually establishing a new TCP connection for every command. This indicates that this weird "stuck" state happened while one of the commands was actively running (e.g. in the middle of Neohub._send) -- perhaps the hub froze while processing the command and restarted, but the integration was still waiting for read or write operation to succeed.

A common way to handle such cases is to abort an operation if it takes too long (more than a given timeout value). I am not super familiar with asyncio, but it seems that wait_for can be used to implement such timeout. However, I am not sure what would be the best place to add such timeouts:

1. This library can have a timeout while calling neohubapi (wrap all calls to neohubapi in wait_for)
2. neohubapi can have a timeout for all requests (wrap all calls to _send in wait_for)
3. neohubapi._send can have a timeout for connection opening and read/write operations.

Perhaps doing this as high in the stack as possible (#1) would make more sense, but I am not sure whether asyncio will cleanly close open connections in such case.

Hi, I'm working on a PR for this repo (adding/configuring via integrations UI page it's still WIP and will only be ready a bit later). But that got me thinking about the license of this component. I think there is a problem.

This component is released under GPL version 2 (often software is released under GPL version 2 or any later version but it does not seem to be the case there, there is no mention of "later" anywhere in the source).

Home Assistant is released under Apache 2.0 license which is incompatible with GPL2 (It is however compatible with GPL3).

So I think we need to change license to either "GPL 3", "GPL 3 or any later version" or "Apache 2.0". Probably the latter would be best if you ever hope of upstreaming this component. In any case this would need approval from previous contributors. Any thoughts?

@MindrustUK @jchasey @mpredfearn @Mooseh81

Add support for "Hold" functionality, looks like "Away" but needs a time to 'hold' at a temperature and state for.

DESCRIPTION
Now getting failures in logs and entities and sensors are becoming unavailable after using this integration successfully and largely without issue since about August 2020. The integration was installed via HACS and added to the HA integrations per instructions.

SCREENSHOTS

SYSTEMS

• Device: HomeKit-Enabled Heatmiser neoHub Gen 2 link
• Home Assistant Version: core-2021.3.4 / supervisor-2021.03.6
• Hardware: NUC 10
• Home Assistant Installation: Home Assistant Operating System (HassOS)
• NUC and neoHub both connected to Unify network via CAT6 ethernet

LOGS
1.

Logger: homeassistant.components.climate
Source: custom_components/heatmiserneo/climate.py:171
Integration: Climate (documentation, issues)
First occurred: 12:39:38 (1 occurrences)
Last logged: 12:39:38

heatmiserneo: Error on device update!
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 360, in _async_add_entity
    await entity.async_device_update(warning=False)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 465, in async_device_update
    await task
  File "/config/custom_components/heatmiserneo/climate.py", line 171, in async_update
    _, devices = await self._hub.get_live_data()
  File "/usr/local/lib/python3.8/site-packages/neohubapi/neohub.py", line 370, in get_live_data
    hub_data = await self._send(message)
  File "/usr/local/lib/python3.8/site-packages/neohubapi/neohub.py", line 84, in _send
    raise(last_exception)
  File "/usr/local/lib/python3.8/site-packages/neohubapi/neohub.py", line 57, in _send
    data = await asyncio.wait_for(
  File "/usr/local/lib/python3.8/asyncio/tasks.py", line 501, in wait_for
    raise exceptions.TimeoutError()
asyncio.exceptions.TimeoutError

Logger: neohub
Source: /usr/local/lib/python3.8/site-packages/neohubapi/neohub.py:73
First occurred: 12:39:38 (166 occurrences)
Last logged: 13:54:43

[1] Timed out while sending a message to 192.168.1.32

Logger: homeassistant.helpers.entity
Source: custom_components/heatmiserneo/climate.py:171
First occurred: 12:40:44 (165 occurrences)
Last logged: 13:54:43

Update for climate.mas fails
Update for climate.off fails
Update for climate.men fails
Update for climate.lau fails
Update for climate.the fails
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 277, in async_update_ha_state
    await self.async_device_update()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 473, in async_device_update
    raise exc
  File "/config/custom_components/heatmiserneo/climate.py", line 171, in async_update
    _, devices = await self._hub.get_live_data()
  File "/usr/local/lib/python3.8/site-packages/neohubapi/neohub.py", line 370, in get_live_data
    hub_data = await self._send(message)
  File "/usr/local/lib/python3.8/site-packages/neohubapi/neohub.py", line 84, in _send
    raise(last_exception)
  File "/usr/local/lib/python3.8/site-packages/neohubapi/neohub.py", line 57, in _send
    data = await asyncio.wait_for(
  File "/usr/local/lib/python3.8/asyncio/tasks.py", line 501, in wait_for
    raise exceptions.TimeoutError()
asyncio.exceptions.TimeoutError

CONTEXT
This integration has worked very well for me previously and I enjoy using it as it enables me to turn on the heat when there is ample solar power to run it and switch it back off when the solar drops down. This effectively allows me to heat my home very economically and I enjoy having the temperature sensor readings for each room.

I've been noticing problems in the log files and this integration's climate sensors going unavailable for the last few weeks. Searching the interwebs hasn't got me any closer to solving the issue.

Today I completely removed the integrations (HA and HACS) and re-added them in the hope it would solve the issue. It didn't. Log entries represent the past 1-1.5 hours since re-adding the integration. The integration added back into HA without issue and the neoHub connected very quickly (i.e. < 1 sec).

The network reports as fine and traffic seems normal. Unify rates the "client experience" as 100 (out of 100) so I don't see an issue there.

There are 15 circuits connected to my system however the integration only added 14 back in today. The circuit known as "XAR" is missing. It previously was there (I have it in Node-RED but it is now "could not find state with entity_id "climate.xar"").

I tested from the Heatmiser iOS app to my system today. I was able to turn a circuit on and off and it responded quickly to both commands.

I waited until a circuit came up in the logs as failed (i.e. "Update for climate.spa fails") then I went to that entity within HA and turned it on. The circuit came on and within a few seconds was reflected in the iOS app as on. I then switched it off and it updated in the iOS app accordingly. Interestingly, after running this test, the failure entry in the logs for that circuit disappeared. As such, you wont see "Update for climate.spa fails" in the log entries above but it was there until I ran this test.

Not sure what else to tell you. Please let me know if further info required or if I can help with testing.

It would be a huge help to be able to change the profile a stat is currently reading. Editing the profiles is okay still in the native app, but to be able to create an automation for stat to switch between 'working from home mode' and 'i'm out the house' mode the day before would be helpful. this is much more powerful than setting a 'hold' as i can create automations that reset after 24 hours
new docs show profiles are accessible

Following error appears in the Logs during startup

WARNING (MainThread) [homeassistant.loader] No 'version' key in the manifest file for custom integration 'heatmiserneo'. This will not be allowed in a future version of Home Assistant. Please report this to the maintainer of 'heatmiserneo'

NeoAirs are battery operated and the API appears to have a LOWBATTERY field, an attribute exposing this would be very useful.

Hi, the error in this seems different from #61 so I have logged a new bug.
I have been happily using this integration for a long time so thanks for all the hard work. I updated via HACS this morning and HA no longer connects to any thermostats

I get this error in the logs after I rebooted HA

2021-01-19 08:11:29 ERROR (MainThread) [homeassistant.components.climate] Error while setting up heatmiserneo platform for climate
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 199, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/heatmiserneo/climate.py", line 56, in async_setup_entry
_, devices = await hub.get_live_data()
File "/usr/local/lib/python3.8/site-packages/neohubapi/neohub.py", line 343, in get_live_data
thermostats.append(NeoStat(self, thermostat))
File "/usr/local/lib/python3.8/site-packages/neohubapi/neostat.py", line 53, in __init__
self.prg_temp = self._data_.PRG_TEMP
AttributeError: 'types.SimpleNamespace' object has no attribute 'PRG_TEMP'

I get the same error for the switch.
I am happy to provide any logs or more details to help diagnose the issue.

get_live_data gets called at the top of async_update and if I understand correctly, this gets called for each entity. I have 10+ devices which means that a) we are hammering the hub b) it takes a while for a thermostat to update since these calls are quite slow.

What is the right way of dealing with this? Should we implement a cache within NeoHub or is there a neat way to deal with it in HomeAssistant?

Thanks for the great work on this component.

I'm having issues getting the component configured in to my setup.
Any chance for documentation?

I've downloaded the script to
config/custom_components/climate/heatmiserneo.py

I rename this to heatmiserneo/climate.py due to info from the logs.

Configuration.yaml:

climate:

• platform: heatmiserneo
  host: a.b.c.d
  port: 4242

Had to investigate a bit to find out which IP was to the Heatmiser Neo. nmap -Pn and looking for port 4242 solved it (something for the docs?)

Both my neo-thermostats show up perfectly and I can set the temperature for both. Very nice.

• How do I set the "HOLD" function? When somebody comes home, or I'm going to sit in the study for couple of hours, I usually set the HOLD function to boost the temperature for some time.
  No big deal if this is not implemented, I'll figure a way to just reset it back to a regular temperature. Working on getting multiple subdomain nginx/caddy/traefik up and running so I can get node-red working, but that has proved really difficult to get working.

• Any chance of implementing the neoPlug? It's a Heatmiser 220v / 110v plug, that can be turned on and off. I got one for free. It shows up as a thermostat with 255 degrees. Tried to turn it off to see if that changed the degrees, but it didnt.

Keep up the great work!

Hey,

I've noticed on the history (and I guess on the live status) that the pre-heat times don't show up as "heating".
So my history looks something like this:

You can see the temperature go up from the pre-heat but I would expect it to show as heating.
The change to support pre-heat seems trivial and I'm happy to submit a PR... However, I wanted to check how others felt about this as I appreciate that it may not be everyone's preference.

So I see three options:

1. Change so that heating is device["HEATING"] == True or device["PREHEAT"] == True
2. Add a configuration option to toggle on "Heating to include pre-heat"
3. I just fork the repo and make change locally just for me.

Thanks in advance

I've just successfully set up an integration for my two Heatmiser Neo stats using this great component. I can see my two thermostats and control the set point in HA.

But I'm not getting any logging. I've set up the following in my configuration.yaml file:

logger:
  default: warning
  logs:
    homeassistant.components.flic: debug
    homeassistant.components.climate.heatmiserneo: debug

I'm not getting anything in the log at all, even though the heatmiserneo component seems to be working (mostly). By contrast, the flic component is producing logging messages, as expected.

Any ideas what might be wrong? I'm no expert (at all) on HA components, but the code looks like logging should do something...

Hi there,

I was running my HA version 0.109.6 with Heatmiser-for-home-assistant which was working well and found my 5 Neostats with no issues.
After upgrading to HA 0.110.1 my Neostats are no longer found and the entities don't exist. Is there any update to my config I need to do?
I've loaded the latest climate.py updates from a few days back

Not much going on in the debug logs:

2020-05-30 16:43:55 DEBUG (SyncWorker_7) [custom_components.heatmiserneo.climate] Entered update(self)
2020-05-30 16:43:55 DEBUG (SyncWorker_7) [custom_components.heatmiserneo.climate] json_request: {'INFO': 0} 
2020-05-30 16:43:56 DEBUG (SyncWorker_7) [custom_components.heatmiserneo.climate] json_response: {"devices":[]} 
2020-05-30 16:43:56 DEBUG (SyncWorker_7) [custom_components.heatmiserneo.climate] update() json response: {'devices': []} 
2020-05-30 16:43:56 DEBUG (SyncWorker_7) [custom_components.heatmiserneo.climate] json_request: {'INFO': 0} 
2020-05-30 16:43:56 DEBUG (SyncWorker_7) [custom_components.heatmiserneo.climate] json_response: {"devices":[]} 
2020-05-30 16:43:56 DEBUG (SyncWorker_7) [custom_components.heatmiserneo.climate] {'devices': []}
2020-05-30 16:43:56 INFO (SyncWorker_7) [custom_components.heatmiserneo.climate] Adding Thermostats: [] 

config setup:

climate:
  - platform: heatmiserneo
    host: 192.168.1.116
    port: 4242
    
logger:
  default: warning
  logs:
    custom_components.heatmiserneo: debug

Upgraded Home Assistant to 0.96 today. There's a breaking change in this release due to a heavy revision of their Climate component

Getting the following error:

Platform not found: climate.heatmiserneo

Would really appreciate if you can have a look into it. Thanks

Cheeky request to add support to report the floor probe temperature, if and when someone has the time and desire.

I used to use this in OpenHab, before switching over to HA, to trigger a temporary rise to the set level if the floor temp dropped below a threshold. It was great as a few rooms wouldn't get cold enough to need warming, but the floor would get cold as the floor is suspended.

I'm just a hobbyist coder so don't think I can get my head around how it was done, looks to me like the engineer's data was used...
https://github.com/openhab/openhab-addons/tree/main/bundles/org.openhab.binding.neohub

I've noticed that my NeoStats lose time reasonably quickly (they seem to run slow). There are a couple of commands that can sync the stat clocks (and set DST). So it would be handy to have a custom service that could invoke the commands every so often (triggered by an HA automation). I'd do a PR, but I'm not too sure how to do custom services (and a little lazy).

Something like the following would work:

def sync_clocks(dst_on = False):
    response = json_request({"MANUAL_DST": 1 if dst_on else 0})
    response = json_request({"NTP_ON": 0})

Interested in your thoughts.

Every time I add the URL into Home Assistant so I can install this it just gives me a error. Is there a know issue just now?

Many Thanks

Add support for NeoPlug devices.
These behave as time clocks and present with ID6. Need to add a "Switch" component for HASS.

#75 adds support for new hvac modes. These modes are hardcoded however there are 2 minor problems with this:

1. Some hardware thermostats may not support some modes
2. Even though a thermostat has support for something, it does not mean that the user has equipment to actually use that mode. For example, if the thermostat may support HVAC_MODE_FAN_ONLY but the user may have no fans.

In both cases, we should not show modes/ui for modes that are not meaningful to the user.

The easiest is to provide some configuration, per thermostat. Bonus would be to infer the default configuration for point 1 at least.

Say your temperature is 20 and you change your target temperature to 25, the hardware thermostat updates almost immediately. However, the home assistant thermostat will show Idle until the next execution of async_update which could happen much later

What is the right way of dealing with it? One way could be that when the target temperature is changes, we call async_update explicitly. Any issue with it?
If we fix #76 I would hope that it would make the change almost instantaneous

Ok, so I thought I would start working on a crude switch type to implement a NeoStat running in timer mode. I have the basic outline of the switch component with a basic on/off, and have it building the device up based off of the info JSON return.

What I would like to know is where you found out the JSON structures for the requests to be sent to the neohub. How did you find them out, or what was the resource you used?

Thanks!