… and the Wiser devices now switched to the expected states as the HeatHub schedule time “jumped” forward.
As you say, the UnixTime showed UTC throughout.
p.s.
Setting the Wiser App to Central European Time set
Excellent. I’ve updated my response. I was not sure if the offset was in hours, minutes or seconds. In hindsight minutes or seconds would have been more likely as that accommodates some Indian or Australian locations using 15 or 30 minute offsets to the hour in their timezones.
Testing the updated passive mode on 3.3.1 and the new temperature increments option doesn’t seem to be being used; its using the old 0.5 increase for me (which doesn’t open the valve enough on the room/radiator id use passive on)
Sorry for the disturb,
the daylight saving was enabled correctly but I forget that the time changed and I don’t adapt the schedules.
To prevent this, we need to have a special time in Wiser Home App sunset + added with a delay.
For example : sunset + 0:30 minutes. @msp1974 that could be in the integration 4030 as special time of a schedule.
Having looked back at the code, you are correct. Its not working as it only sets it at start up but needs to set on update and it doesn’t which resets it back to default (0.5).
Can you please log this as an issue on our github and I will fix for next release.
No, this is a function of the hub (as is the schedule execution). The only thing the integration does it set the schedule in the hub. 3000 and 4000 are times that the hub understands and we can’t just create new ones. As such, unless Wiser add a delay to sunrise/sunset, it can’t be done.
You could however, use the fantastic schedule integration on HACs to set ‘manual’ schedules in HA that execute commands like open/close shutters etc. But this is then off hub and any drop in wifi will stop it working.
I know that, but I was dreaming that one day Schneider Electric…
The value 4030 is in fact what we can use to tell the hub .
Of course I use the fantastic, the famous schedule integration on HACs to set ‘manual’ schedules very often
Question on the Geo/Insights+ system: is there any benefit at all in using this system if you already get real time electricity data via an optical sensor and batched electric and gas data via the bright app integration?
I’m trying to work out why you’d get an extra device for something bright offers for free without an extra IHD, if it’s the same thing.
Insights+ is pretty pointless if you’re already getting usage data elsewhere.
It’s standard usage and budgeting reports (with really hard to use line graphs) with some Wiser specific gimmicks (heating predictor, smart savings, did you know type stuff). Oh, and it tells you how many trees you need to plant to offset your carbon footprint.
I only got it because I have having problems with my existing IHD. Helpfully it enables integration with HA but I haven’t looked at it for ages (other than to check what it did for this post).
Thanks! So, what data exactly can you get via Insights+?
real-time or 30-minute batched up electricity data?
real-time or 30-minute batched up gas data?
Also is the data you get via insights+ retrieved ‘locally’ via a direct connection from HA to the Geo device, or is it retrieved by HA via the geo cloud via an internet connection and http requests?
My current assumption is that the Geo device connects to the meters via zigbee locally to get the data, but then uses wifi to send any data to the Geo servers. Then HA retrieves the data from geo servers.
I wonder if we could make the geo device send the data to HA directly instead of sending them to the Geo servers. Could perhaps be possible if this is done via MQTT between geo and geo servers by intercepting that connection. That would be similar to how localtuya works.
As a new owner of smart meters (having previously had really great h/w devices on my dumb meters to share the usage data with HA), I researched how I can get this same data into HA locally.
The answer is basically, you can’t. The only way to access smart meter data is via a registered vendor who can access the data from the central source (max 30 min increments) or via an IHD from a similar registered vendor such as GEO.
Each of these devices then connects via zigbee (with a protocol not supported by all the usual zigbee sticks and unregisterable for non approved vendors) and sends data to the vendor cloud. This can then allow access to realtime electricity data (depending on the IHD device you have) but a max of 30 min interval gas data as the gas meter does not send any data on zigbee on more than a 30 min freq to conserve battery in the meter.
GEO does seem to be the best for a number of reasons:
It does capture current usage data (not all do)
They have probably the best api to then access that data
It is the integrated Wiser option for Insights+ but also has a HA integration to get directly from GEO into HA energy dashboard.
I would say that all my research determined that the data from Smart meters (which is suposed to be owned by the customer ie you and me) is generally hard to get hold of and you have somewhat limited options to do this, all of which are cloud based and rely on a api from the vendor (which vary in capability). In reality, I wished I had not bothered changing to smart meters as the solutions I had for my dumb meters was actually better and gave more granular data.
You can however (via GEO integration) also get your tariff info to calculate costs in HA energy dashboard.
This article was very helpful to me in understanding all this and what options there are.
EDIT: For anyone reading this for future ref.
It does appear that the Hildbrand Glow does allow local MQTT access from the CAD (it still sends this info to the cloud afaik however).
I use Hildebrand (Glow) and their CAD. I get per second updates from Electricity and the normal 30mins for gas consumption. It has an MQTT feed.
This is used directly in the HA energy dashboard.
It is a good solution.
A. Insights+: per-second electricity and 30-minute gas readings, via Geo cloud API. Needs purchase of a device, not too expensive, but internet-only. Possibly some minor delay due to cloud round-trip connection.
B. Hilderbrand Glow CAD: Same per-second electricity and 30-minute gas readings, via Hilderbrand cloud API. Needs purchase of their CAD that is more expensive than Insights+. Internet only again. Possibly some minor delay due to cloud round-trip connection.
C. Hilderbrand free Glow API without CAD: Gives access to 30-minute electricity and 30-minute gas readings, via the DCC. Free, no CAD, Some delay due to internet/DCC round-trip, no real-time electricity readings.
D. Building up a esphome device with an optical/reed sensor to read electricity meter directly: Best solution for electricity, instant real-time readings without cloud. Cost to build this device probably similar to insights+ CAD (under 20gbp). Some gas meters may also allow a similar device, but typically SMETS2 smart gas meters do not have magnets or LED counters on them to save battery, so that wouldnt work.
Combining C+D will give you local real-time electricity data and 30-minute gas data via internet, with only cost of the esp8266 device and a few parts.
Alternatively A looks to be the best option (Insights+), as it’s cheaper than B.
Someone who already does C+D wouldn’t benefit from solutions A or B.
I don’t think the Magakid integration (which is based on the link I posted above) is supported anymore.
All the info is in the link I posted and there is even a link to a blueprint for the Hildebrand CAD in the post.
Further consideration is the Wiser insights + is not available to everyone with a smart meter. I have SMETS2 meters installed and Wiser cannot see them but Hildebrand can.
You can create the sensors using the MQTT platform in Home Assistant though, as detailed in the video, can’t you, even if the integration is no longer supported/working? I’m hoping so anyway, as this is the path I plan on taking once I know whether my SMETS1 meters are going to be upgraded or replaced. I don’t believe I can order the Hildebrand Glow until I know that as there are two different versions, one for SMETS1 and one for SMETS2. Either way I think they need to be talking to the DCC for Hildebrand to commission the Glow to connect to them, if I am understanding everything correctly.
I know that, but I was dreaming that one day Schneider Electric…