I’ve been tweaking the code to support the older hardware and parse non-electricity datagrams. Once I’ve tested some more I’ll post an update for this.
1 Like
I’ve issued a pull request on github to support the older hardware and parse (ignore) the the non-electric datagrams. In addition I now pull out the heating and hotwater temperatures as additional sensors. However this has highlighted a structural issue with the current code.
Since the different data comes from discrete sensors, each sensor has its own battery and radio levels, and currently it is assumed there is only one of these overall.
One approach to fix this would be to instead create a sensor for each physical device that the Network OWL reports on and make the battery and radio sensors attributes of these core sensors.
Any thoughts on this from @glopresti or other users?
The pull request is merged (thanks!). For the extra sensors, no strong opinion but I’d slightly prefer to have multiple entities for each measurable ‘thing’ (including battery/radio levels) as opposed to attributes. E.g. NetAtmo follows the same principle and creates many multiple sensors for all their devices.
I think we can work together on Github to get there with appropriate naming conventions. On the other side, what remains a missing feature to make this integration part of HA is the async updates… will see if we can manage that too.
Hi there,
I managed to spend some time to test the new OWL component (but not yet the custom updater). I’ve pushed a few minor fixes and I have reintroduced the dynamic refresh interval (even though it’s still pretty heuristic).
Could you please test it (at https://github.com/custom-components/sensor.owlintuition)? then I guess I’d post it in the forum. Comments welcome!
Does it still crash HA after a few hours?
Yes have pulled down the latest code and it now updating with the custom_updater/tracker card!
It doesn’t, as it is not async - and you get your logs full of warnings that the updates take time.
The async code is still to be re-tested and sorted out, I won’t push this component to be part of HA until that’s done.
@jchasey great to hear that!
Hiya.
My HA has been offline for the past year due to cgnat on my broadband. I’m back online now.
Is this owl code also for solar ?
Thanks in advance.
Mitch - 18days
1 Like
I need to try this, I currently use my own python script that just does usage, generation and export. Will your script run in hassio?
I use it on a standard docker-based setup, but I seem to remember that it was used in hassio. Of course you need to make sure that hassio is able to bind and listen to the UDP port where OWL pushes the data.
It is working perfectly in hassio. Thank you very much for all of your input on this!!
Q - Will this still work on the lan when my owl subscription expires in a few months time ?
I just set this up and it’s working but I have a few questions.
I currently have a python script that picks up the multicast packets and publishes values to Mqtt, this seems to update more frequently than your component. My script runs on another pc on my network. What controls the update rate of your addon?
Is it possible to receive the multicast packets addressed to 224.192.32.19:22600 instead of push data?
What happens if a message is not received, such as if the owl intuition lost power. I control switches based on this data, in my current setup, i set expiry times on the Mqtt sensors I have configured.
I don’t need all the sensors, is there a way to hide or turn them off?
It should work ok on the lan. Make a note of your api key from the website. You need it to change settings. Multicast packets are definitely broadcast on the lan without the internet.
Thanks, I’ve saved it. Although I’m guessing you meant UDP Key in the data push settings rather than api key which I cannot locate.
Yeah, that’s it. You need it to send commands via the command line to change things on the owl gateway that you would normally do on the website.
1 Like
Hi,
Back to your questions, the platform refreshes the sensors every 60 / <# of sensor classes> seconds: this comes from my observation that the electricity sensors get updated every minute, and I made the rough assumption that other sensors refresh as often. That is a workaround until I manage to get the listening part asynchronous (I have some ideas on how to redo that), which will allow to not miss any update.
I didn’t investigate whether it is possible to listen to the multicast packets (which would include making sure that HA or hassio are able to get them), but feel free to try and report about that.
Finally, about ‘expiring’ stale data, that’s a nice suggestion. At the moment nothing happens - sensors report their last data point. Could you provide more details about your MQTT sensors implementation and file an issue at https://github.com/custom-components/sensor.owlintuition/issues please?
And about hiding sensors, aren’t they already hidden if you use the typical group: configuration? I explicitly include the ones I wish to show in the UI. We did the change to only allow specifying the “class” of sensors in the config as opposed to listing each of them given that the list was getting pretty large.
Hi, I don’t have enough experience of HA coding to quickly come up with solution to listen for multicast packets but I am happy to share the python code I am using at the moment to listen for the multicast packets and publish to MQTT. The code is something I have pieced together and is not all my own work. It would be great to run it on my Hassio Raspberry pi but at the moment I run it on python on a windows PC on the same network.
I understand by default the owl broadcasts multicast packet after every update on the local network to 224.192.32.19:22600. The code below receives these and takes out what I need (probably not in the best way, but I struggled with using python) and puts it into variables. It writes them to a website html file which I was going to try and receive with a template sensor in HA but ended up adding the lines of code to publish directly to Mqtt. I then configure mqtt sensors in HA to retrieve these with an expiry time set.
Python code running on a separate PC
# Multicast client
# Adapted from: http://chaos.weblogs.us/archives/164
import socket
import re
import time
import paho.mqtt.client as mqtt #import the client1
import paho.mqtt.publish as publish
elecdata = ("Start")
matchelec = ("Start")
matchsolar = ("Start")
ANY = "192.168.1.XXX" #IP of interface to listen on
MCAST_ADDR = "224.192.32.19"
MCAST_PORT = 22600
client = mqtt.Client("P1") #create new instance
client.username_pw_set(username="mqttuser",password="mqttpassword")
client.connect("192.168.1.XXX") #connect to broker
client.loop_start()
# Create a UDP socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
# Allow multiple sockets to use the same PORT number
sock.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1)
# Bind to the port that we know will receive multicast data
sock.bind((ANY,MCAST_PORT))
# Tell the kernel that we want to add ourselves to a multicast group
# The address for the multicast group is the third param
status = sock.setsockopt(socket.IPPROTO_IP,
socket.IP_ADD_MEMBERSHIP,
socket.inet_aton(MCAST_ADDR) + socket.inet_aton(ANY))
# setblocking(0) is equiv to settimeout(0.0) which means we poll the socket.
# But this will raise an error if recv() or send() can't immediately find or send data.
sock.setblocking(0)
while 1:
time.sleep(2)
try:
data, addr = sock.recvfrom(1024)
except socket.error as e:
pass
else:
matchelec = re.match (r".*electricity id=.*", str(data), re.I|re.S)
matchsolar = re.match (r".*generating units=.*", str(data), re.I|re.S)
if matchelec:
elecdata = (str(data))
if matchsolar:
solardata = (str(data))
fulldata = (str(elecdata) + str(solardata))
print (fulldata)
print ("")
matchObj = re.match (r".*<chan id='0'><curr units=\'w\'>([0-9]+\.[0-9]+).*<generating units=\'w\'>([0-9]+\.[0-9]+).*<exporting units=\'w\'>([0-9]+\.[0-9]+)</exporting>.*", str(fulldata), re.I|re.S)
if matchObj:
using = matchObj.group(1)
generating = matchObj.group(2)
export = matchObj.group(3)
from time import ctime
from datetime import datetime
f = open("C:\www\website.co.uk\index.html", "w")
f.write( "<meta http-equiv=\"refresh\" content=\"10\"><body><font size=\"+4\">Generating: "+str(generating)+"<br> Using: "+ str(using)+"<br> Exporting: "+ str(export)+"</font><br><br> Time: "+str(datetime.now().strftime('%H:%M'))+"</body>")
f.close()
#try:
client.publish("sensor/owl/generating",str(generating))#publish
client.publish("sensor/owl/using",str(using))#publish
client.publish("sensor/owl/export",str(export))#publish
configuration.yaml
- platform: mqtt
name: "Owl Gen"
state_topic: "sensor/owl/generating"
expire_after: 300
qos: 1
unit_of_measurement: "Watts"
- platform: mqtt
name: "Owl Use"
state_topic: "sensor/owl/using"
expire_after: 300
qos: 1
unit_of_measurement: "Watts"
- platform: mqtt
name: "Owl Exp"
state_topic: "sensor/owl/export"
expire_after: 300
qos: 1
unit_of_measurement: "Watts"Hi everyone. It’s 10:16 gmt. The owl is totally down for me. Is anyone else’s HA intergration able to still retrieve their current usage/generation? It’s not working for me and I don’t know if it should be or not. Thx
Can you log into the website, is your owl showing offline?
My owl is still sending multicast packets, maybe data push doesn’t work if the servers are down?