Two zones no sensor displayed

[03397]

Guys, when there are two heating zones it is displayed only one the sensors. For example we should have two sensor.owl_intuition_heating_state for the two different zones.

By the way any luck with the async code?

[jchasey]

Agreed, I only have one zone so was unable to test multiple zones. We need to have a naming convention for the extra zones too. Possible option is to append _1 and then _2 etc to the supplied name if multiple zones exist. Alternatively the first zone uses the supplied name, then _2, _3 etc used for any subsequent zones.

[03397]

Why don't you get here zone name as per their dashboard? Isn't this supplied from udp packet?

[jchasey]

No there is just a device id for the zone, no naming details are included. I presume the names set in the dashboard are associated in the cloud only, this data does not appear in the data transmitted to the network owl.

[jchasey]

Thinking about it some more we could append the device id to the name to ensure unique names and then let the user use the friendly_name attribute to override the name that is displayed in the front end. This would also ensure if the order of the data in the XML changed the correct data will be picked up for each sensor. Therefore the sensor name would be something like:

sensor.owl_intuition_heating_200120B_temperature sensor.owl_intuition_heating_200120B_state etc

[03397]

Yes I think this is a good idea. You can append the device id which is unique. Then the nMe can be changed from home assistant.

I am willing to test when you have the time to do it.

Did you have any progress with the async code?

On 12 Nov 2018 12:49, jchasey notifications@github.com wrote:

Thinking about it some more we could append the device id to the name to ensure unique names and then let the user use the friendly_name attribute to override the name that is displayed in the front end. This would also ensure if the order of the data in the XML changed the correct data will be picked up for each sensor. Therefore the sensor name would be something like:

sensor.owl_intuition_heating_200120B_temperature sensor.owl_intuition_heating_200120B_state etc

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/custom-components/sensor.owlintuition/issues/5#issuecomment-437836153, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF3axVMKW0D_JyHN438IN0b_Z2KQEzJFks5uuVIogaJpZM4YZLfM.

[glpatcern]

I'm curious to see what would be the device id for an installation with a single device (like mine ;) ) - we might as well append the device id only if multiple devices are configured and leave the simpler name otherwise.

As for the async, I have some ideas but did not have time yet to give it a try again.

[jchasey]

The challenge is that structurally the sensors are created in advance, but only populated with data when the XML is received. Therefore at sensor creation time we don't know how many to create or what the name should be. I'll see if there are any examples of other sensors they create additional sensors on the fly...

[03397]

Any news on the two zones? I have found out that when the system is in away zone the states of the sensors are in Standby not in Away In addition, the sensor.owl_intuition_heating_battery is always being displayed as low.

[jchasey]

Hasn't been much progress on this, partly because I think we need to rework the architecture...

Rather than simply have a multitude of sensors, we should have a configuration for a hub which will handle the basic comms to the Network OWL.

Then sensors can be created to report electric usage etc.

Plus a water heater component and climate component can be created to cover off the heating and water systems.

The wiser component is a good example covering off sensors and climate, we may be able to address the async approach too. Any thoughts?

[glpatcern]

If we are to rewrite the component using the hub model, then IMHO the async should be part of the refactoring.

Now unfortunately my attempt with some async code didn't work out (and in the last couple of months other work+family businesses prevented me from investing more time...). I guess the wiser component you are referring to is at https://github.com/asantaga/wiserHomeAssistantPlatform, right? but I don't see any async code there...

[jchasey]

I agree on the async front. I wonder if using the explicit request approach rather than the multicast will help with async. Wiser has the right architecture in general but identifying a good existing component that uses async correctly would be useful.

[glpatcern]

That's a good point: do I understand it right that in your case (with the thermostat) you should be able to send data to control the device? In my case I only read from the given IP - not even from the multicast IP address (which could possibly be an alternative).

[jchasey]

Yes there are a set of commands you can send to the device and get a response, however generally the commands are to set values etc, much of the data returned is simply an acknowledgement and the 'real' data in terms of temperature etc still comes via the multicast packets. Also with the new change in architecture of components/sensors in HA, we should wait until this is live and look to base on that. See https://github.com/home-assistant/home-assistant/pull/20527 for the changes to the speedtest component/sensor. This may be a good model as the core component should collect data from the multicast and then let specific sensors know when there is data relevant to them available.

[glpatcern]

I fully agree. In the end, this was born as a simple and pure sensor (for my electricity meter), but it is evolving into a more complex component. Let's see how this goes - and I'm sure async stuff can easily fit in.

[glpatcern]

To resurrect this conversation (which went well beyond the original issue...), I've updated the component following the new layout and I'm using it with HA 0.90 without issues. Of course this was a simple renaming, but @jchasey may want to look into transforming this component using the hub model, given what else from the OWL network could be integrated.

[glpatcern]

As there seems to be some cleanup going on, I'm considering closing this issue because of no acivity. Any opinions about its future?

[lukewest]

I’m about to add a second electricity monitor to my setup, so I'll see how it goes. I’m not a coder, so reworking the async piece is beyond me.

[glpatcern]

Let's see what is your experience. Meanwhile, my idea is to change approach and introduce a proxy server in between, which would gather all info sent by the OWL devices and to which HA would connect, as opposed to be listening itself.

Pros: this issue and all warnings will be gone, HA will never wait. Cons: one more little container/daemon to run somewhere in our infrastructure.

(This idea was discussed in the HA forum already months ago, but so far I did not find the time to work on it. So no promises yet...).

[glpatcern]

Resurrecting this old issue: given the recent updates (see e.g. https://github.com/custom-components/sensor.owlintuition/issues/18 where eventually we didn't need the async code), I'd like to know if this is still problematic for someone. @03397 ?

The original problem with multiple zones may well be relevant, so trying to be pragmatic - no big refactoring - may I get a network capture of the traffic generated by such a configuration? This is to try and figure out how to handle the data in the sensors. Otherwise, I don't see how to fix it.

Closing for now but happy to reopen if there's a reply.