Owl Intuition pv & Home Assistant

Hey @glopresti

Im kinda of new to the home Assistant community , and i can say im loving it.

I to have a owl intuition and running Hass.io and i can no for the love of god get them to work together.
Ive looked at your GitHub, and currently using your script (nice job btw). but im stuck.

Well here are my steps
-Ive gone to the owl intuition an pointed the push data UDP to my hass.io IP
-Installed your script in the config folder custom_components/sensor
-created the sensor and the group.

all apeares in the dashboard but as unknown.
41

and if i go to the logs i get these errors

2018-04-13 12:30:24 ERROR (SyncWorker_8) [custom_components.sensor.owlintuition] Unable to bind on port 3200: [Errno -2] Name does not resolve
2018-04-13 12:31:26 ERROR (SyncWorker_17) [custom_components.sensor.owlintuition] Unable to bind on port 3200: [Errno -2] Name does not resolve
2018-04-13 12:32:28 ERROR (SyncWorker_10) [custom_components.sensor.owlintuition] Unable to bind on port 3200: [Errno -2] Name does not resolve
2018-04-13 12:33:30 ERROR (SyncWorker_12) [custom_components.sensor.owlintuition] Unable to bind on port 3200: [Errno -2] Name does not resolve
2018-04-13 12:34:32 ERROR (SyncWorker_7) [custom_components.sensor.owlintuition] Unable to bind on port 3200: [Errno -2] Name does not resolve

what could i be missing, I’ve bean at it a few day and cannot figure it out.

Hi @australian,

The 'Name does not resolve' error suggests that from your hass.io you cannot resolve hostnames, but then I don’t understand how it can connect to other components: do you have other working sensors?
Anyway to further troubleshoot your setup, can you get a shell inside hass.io? (I don’t know the details of that, I personally use homeassistant inside a docker container)

If yes, try to launch python and then execute the following:

import socket
print socket.getfqdn()
print socket.gethostname()

I expect the getfqdn() to fail, but maybe gethostname() works and the OWL sensor could be adapted to use that. Also, you might hardcode the IP address of your hass.io (but I’d make it a configuration parameter - I can’t do this modification now but may work on that).

1 Like

I’m new to HA and have an Owl Intuition can anyone please help me get this working?

I’ve added the following to my configuration.yaml file:

>   - platform: owlintuition
>     port: 3200
>     mode: monophase       # default is monophase
>     monitored_conditions:
>       - battery
>       - radio
>       - power
>       - energy_today

I created a folder under my config folder called “customer_components\sensor” and copied the script from github to a file called owlintuition.py and placed it in the sensor folder.

I’m not sure what I need to do in the push data settings in the owl in the web interface, am I just pointing it at the internal IP of the HA instance?

When I add the above owl sensor to my configuration.yaml file and then check config it gets stuck and won’t validate the config or restart until I delete the sensor owl sensor from HA.

Any ideas please?

hi bcowell.

don’t know if you had any luck, but after a lot of help for glospresti have you tried using the sensor with this configuration

– platform: owlintuition
port: 3200
mode: monophase
host: (ip of HA)
monitored_conditions:
– battery
– power
– energy_today
– radio

Ive been away for a while. let me know if can help in getting yours to work

1 Like

No I gave up on it and couldn’t get it to work, thanks for replying!

I’ll give your config a go and reply back. Besides the config above I’ve put the owlintuition.py file in config\custom_components\sensor folder do I need to do anything on the owl device?

Hi there,

Sorry for having missed your first post, anyway a priori what you did is all correct (including the push settings in the OWL web interface). What do you see in the HA logs?

Also, can you make sure you are receiving data on the box where HA runs? To validate that, you may try and get the OWL data outside of HA. Try something like https://github.com/glpatcern/domotica/blob/master/demos/owlintuition.py

And finally, note that a recent update of the OWL firmware broke the XML format (but they should be deploying the fix, I got it after asking their support).

Hope this helps.

1 Like

It’s working now I just had to put the Host IP Address in configuration.yaml file. Thank you both for your help.

One more question, can I get this to show What my solar system is currently generating and total generation for today? How often does the data get refreshed?

1 Like

Good, thanks for reporting that.

For your questions: the data is refreshed every minute, and about your solar system, of course I can’t say. But if you have another current clamp on its output you should be able to get your data. You can play with my demo above to look at the full XML data and check what you have.

1 Like

Hi, to add to the above: I realized that OWL explicitly supports solar panel systems.
If you send me the XML you get e.g. by running my demo, I can try and integrate a sensor for the solar panel.

Yes I can see my Solar generation in the Owl app. How do I run the demo?

Simply run the script (python owlintuition.py) from the same box where you run HomeAssistant - stop HA if you wish to use the same port. Within a minute it will print the XML packet received from the OWL base station.

Yeah sorry no idea how to run it, I know nothing about python or how to run the script. I installed python on my windows desktop and pointed the push data settings on my owl to my windows desktop and run it but still not sure what I’m doing.

Hi
Did you have any luck moving to an async model?

Hi,

Nope. I got the solar generators supported thanks to @bcowell, but at that time my several attempts at getting the async way working failed both for me and for him - we had Home Assistant randomly crashing every couple of hours.

If you want to have a look at the last version, it’s here:

But despite not producing any error and working fine for some time, it crashes HA.

Thanks for the update, I’ve been playing with my setup and have discovered a number of idiosyncrasies with the OWL system that I thought worth mentioning in case it helps anyone else. I have two Network OWLs running at two different properties so have been able to identify a range of issues.

First of all the older generation of hardware used a fixed IP address for firmware updates. The company no longer controls that IP address and therefore the older hardware cannot be updated unless it received an interim firmware update while they still controlled the IP address.

The older generation hardware has a MAC address beginning ‘4337190’ and the newer generation MAC ID should start ‘4437191’. There is still stock on shelves with some retailers that is the old hardware so if buying a new device get them to check the MAC address before purchasing.

The older generation hardware latest firmware is 2.8:1096 whereas the new generation is at 4.3:608 and the XML that is transmitted is slightly different!

If you have an older Network OWL the XML format of the datagram does not have the version 2.0 attribute and is missing the tag, sample XML as follows:

<electricity id='44371900413F'>
	<timestamp>1537276490</timestamp>
	<signal rssi='-83' lqi='124'/>
	<battery level='100%'/>
	<chan id='0'>
		<curr units='w'>1094.00</curr>
		<day units='wh'>17120.14</day>
	</chan>
	<chan id='1'>
		<curr units='w'>0.00</curr>
		<day units='wh'>0.00</day>
	</chan>
	<chan id='2'>
		<curr units='w'>0.00</curr>
		<day units='wh'>0.00</day>
	</chan>
</electricity>

If you also have the heating controls from OWL, then additional datagrams are multicast between each update as follows:

> <heating ver='2' id='44371900413F'>
> 	<timestamp>1537276534</timestamp>
> 	<zones>
> 		<zone id='200167D' last='1'>
> 			<signal rssi='-79' lqi='49'/>
> 			<battery level='2780'/>
> 			<conf flags='0'/>
> 			<temperature state='0' flags='0' until='1537286400' zone='0'>
> 				<current>19.05</current>
> 				<required>15.00</required>
> 			</temperature>
> 		</zone>
> 	</zones>
> </heating>
> 
> <hot_water ver='2' id='44371900413F'>
> 	<timestamp>1537276511</timestamp>
> 	<zones>
> 		<zone id='200120B' last='1'>
> 			<signal rssi='-71' lqi='49'/>
> 			<battery level='2670'/>
> 			<conf flags='0'/>
> 			<temperature state='0' flags='0' until='1537282800'>
> 				<current>54.00</current>
> 				<required>10.00</required>
> 				<ambient>23.75</ambient>
> 			</temperature>
> 		</zone>
> 	</zones>
> </hot_water>
> 
> <relays var='1' id='44371900413F'>
> 	<timestamp>1537276470</timestamp>
> 	<zones>
> 		<zone id='2101FB8' last='1' relay='0'>
> 			<signal rssi='-87' lqi='49'/>
> 			<conf flags='0'/>
> 			<devices>
> 				<device address='200167D' relay='0' rssi='-75'/>
> 			</devices>
> 		</zone>
> 	</zones>
> </relays>

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!