Unifi Network with EVE Energy, EVE Door & Window, EVE Motion

[flint ledge]

Yesterday I installed the latest HA updates and reinstalled the Matter integration.

After that I shared my three EVE Matter devices from Apple Home with Home Assistant. Pairing procedure was without issues for all three devices.

EVE Energy:

• works as expected at the moment

EVE Door & Window:

• works as expected at the moment

EVE Motion:

• „Illuminance“ seems to work, values are changing
• „Occupancy“ doesn’t work, it’s always „Clear“, even though motion is detected in the EVE and Apple Home app

It gets better and better. Well done! 😃👍

Now let’s wait and see, if the devices are stable/reachable in a long time test.

By the way…, these three EVE Matter devices work as expected since round about 6 weeks. In the last 6 weeks they were paired to Apple Home only.

I am one of the guys with a Ubiquiti Unifi Network:

• UDM-SE
• USW-Aggregation
• USW-Enterprise-24-PoE
• 3x U6-Enterprise
• 3x U6-Pro

Network settings:

• IGMP Snooping enabled for all VLANs
• Multicast DNS enabled for all relevant VLAN incl. Main VLAN

Wifi settings:

• Multicast Enhancements enabled for the relevant SSIDs

The Main VLAN is where Home Assistant OS instance and all my Apple and Sonos devices reside (I have only one AppleTV4K, as a Thread Border router). No VLAN separation present for my Matter/Thread devices.

Now where my Matter devices were stable/reliable for 6 weeks, I think I can say that my network settings (IGMP Snooping, mDNS) are not a problem for reliability issues. 😉

——————————
Ok, checked the status of my 3 Matter devices in HA one hour after pairing.

My EVE Door & Window stays in the „Closed“ state, even though it works as expected in Apple Home and in the EVE app.

Unifi Network with EVE Energy, EVE Door & Window, EVE Motion

Do we need tickets for the not working EVE Motion „Occupancy“ and EVE Door?

[sonic swift]

I also have ubiquti setup with HA running on bare metal, it isnt a good experience with matter. my eve energy works (no stats) but motion is bugged out

just gonna have to have for new eve firmware

[flint ledge]

I read on Reddit that we maybe see a new EVE firmware for EVE Motion and EVE Door & Window in the middle of April 2023. They are going to launch the Matter version for these device types on April 17.

@sonic swift What are your IGMP and mDNS settings in your Unifi network?

[sonic swift]

IGMP snooping : off
mDNS : on

whats yours?

@flint ledge

[flint ledge]

Network settings:
IGMP Snooping: on
Multicast DNS: on

Wifi settings:
Multicast Enhancements: on

[sonic swift]

my multicast is off

both in wifi, and network

honestly, i think we just gotta wait for new firmware from eve

[flint ledge]

In the last post you wrote mDNS is on… What’s the truth? 😂

[sonic swift]

wait

shit

MulticastDNS: on
IGMP snooping: off
multicast enahncement: off

[flint ledge]

Ok, thanks.

Let’s stay in contact here for this EVE issues.

[sonic swift]

Sure thing, i feel we just gotta wait for new firmware

[flint ledge]

Yeah, I share your feeling… 😃

[rancid temple]

I turned off multicast enhancements and multicast dns (as I ditched the separate vlan anyways) and it has been stable since but I'm probably not the best person to test because I keep re-adding devices to my network for testing 🙂

multicast enhancements are meant for crowded office environments where you want to keep the amount of multicast traffic as low as possible. In home networks you should turn off options like that as these protocols (matter, homekit, airplay etc.) are not built for that, they heaviliy rely on multicast so dont try to be smart to filter it.

[flint ledge]

What of your devices exactly have been stable since you turned the Multicast DNS and Enhancement off?

My setup is absolutely stable since 6 weeks now. Only Matter devices in HA are a bit problematic. The rest is fine.

[rancid temple]

Chromecast devices now stay connected for instance, also the HP printer stays online. As for Matter hard to tell as I keep restarting my dev server and resetting devices but the Eve energy plug is now staying online while it dropped off the network very often before that.

This issue is not new, Unifi has always had issues like this.
I guess thats what you get when you get office equipment into your home 😉

Unless you have a very crowded WiFi setup with really a lot of devices, you can safely turn off multicast "enhancements". Heck, every home-grade wifi router will not do any multicast filtering and still perform well.

[flint ledge]

@rancid temple let’s consolidate the EVE discussion in this thread.

Sorry, I was wrong. I logged into my HAOS via ssh, but I was in a ‘container‘. Never really used HAOS ssh before. But when I execute the ping6 commands on the host shell I get the output for all 3 devices that ‘<ipv6> is alive!‘.

[flint ledge]

Ok, I understand your point of view regarding Multicast enhancements. But for me it’s the opposite. My Brother printer, some Xiaomi devices, a HomeConnect device and some other Wifi/Ethernet devices work as expected, since I activated Multicast DNS and Enhancements. But these devices are in my IoT VLAN and I don’t want them in my Main VLAN.

But let me try to disable the mDNS settings today in the evening. I am going to try my luck without this two options enabled. I will report back here.

[rancid temple]

yes, you will actually need multicast dns if you place devices like that in another subnet. It will sometimes work and sometimes not. In the end I just advice to not trap into the enterprise network syndrome and keep the home network simple as manufacturers simply do not care and target at consumer grade networks. If you get it working with tricks like routing mdns traffic (actually modifying the packets!), that is your luck but you will not likely get any support from manufacturers or solutions for that setup. Hence our recommendations to always start simple with a plain layer 2 (same subnet) network and make it more complicated after that if you really want.

[rancid temple]

ah OK, thanks for the info, that is very important to know so looks like the reconnect mechanism is not functioning properly then. Does it come back alive after 2 minutes (more or less) ?

[flint ledge]

No, in the HA interface it doesn’t come back alive. Logbook says Contact was closed 6 hours ago.

[rancid temple]

And nothing in the HA add-on log ?

[flint ledge]

I understand your points. But the EVE Door and EVE Motion issues can’t have anything to with my network config.

The EVE Energy works as expected. Where do you see the difference to the other two device types? 😃

[rancid temple]

Ah no, that was just some response to the talk about network setups. We only provide support to those using a plain network because that is hard enough to track already.

Uhm, the Eve Energy is a routing device and the door sensor is a sleeping battery powered device so I suspect there's an issue there. How does the Motion sensor behave ?

There's some logic offered by the SDK to subscribe to a node's availability which reports to us that the keepalive failed (ping/pong every 120 seconds) and that is the logic that marks the device as unavailable. If the device comes back again we have another callback that the device is back. I suspect there's an issue in that logic and/or the device itself. There's a good chance that apple and google are just polling the device theirselves

[flint ledge]

Ok, as already said, my EVE devices and my HA instance are together with my Apple devices in my Main VLAN. I do not plan to change this. But when everything relevant is in the same VLAN the mDNS settings are not relevant. 😉

[rancid temple]

Correct, but we also see people with the matter devices in another subnet and that is what we do not support atm to keep things simple

Something to test: while the device is unavailable... pull the battery out. wait 10 seconds and put it back in.. does the device come alive again ?

[flint ledge]

In HA „Illuminance“ works fine, but „Occupancy“ stays in the state „Clear“. In Apple Home both works as expected.

[rancid temple]

yes, I know about that and I will address that. I was asking if also goes to an unavailable state

oh wait... does the device actually go into unavailable state or does it just keep in the old state ?

[flint ledge]

No, EVE Motion is not in an unavailable state.

Occupancy state is Clear all the time, even though I am sitting in front of it.

Illuminance lx value changes when I bring the device to the light.

Logbook says Occupancy cleared (no detected) 6 hours ago. That’s the only log.

[rancid temple]

I was actually talking about the Door sensor, so that does also not go to unavailable state ?

[flint ledge]

Ah, ok… 😃

It was in the „Closed“ state all the time.

I removed the batteries for 20 seconds, the device became unavailable in Home Assistant and now is again in the state „Closed“. It works fine in Apple Home again.

If you want me to give you some logs, please instruct me, what you need. The Matter Server Log only shows the last minutes in the Web Interface. Where do I find the complete Matter Server Log?

uff... I restarted my Matter server to change the log level from info to warning. The log looks as follows:

https://pastebin.com/2VsdAVLf

There are some mDNS ERRORs, like this:

ERROR MDNS failed to join multicast group on veth2b660c7 for address type IPv4: ../src/inet/UDPEndPointImplSockets.cpp:764: Inet Error 0x00000110: Address not found
ERROR MDNS failed to join multicast group on veth7c5b09c for address type IPv4: ../src/inet/UDPEndPointImplSockets.cpp:764: Inet Error 0x00000110: Address not found
ERROR MDNS failed to join multicast group on vethf31e105 for address type IPv4: ../src/inet/UDPEndPointImplSockets.cpp:764: Inet Error 0x00000110: Address not found
ERROR MDNS failed to join multicast group on vethc2ae943 for address type IPv4: ../src/inet/UDPEndPointImplSockets.cpp:764: Inet Error 0x00000110: Address not found
ERROR MDNS failed to join multicast group on veth171a819 for address type IPv4: ../src/inet/UDPEndPointImplSockets.cpp:764: Inet Error 0x00000110: Address not found
ERROR MDNS failed to join multicast group on vethcab12a2 for address type IPv4: ../src/inet/UDPEndPointImplSockets.cpp:764: Inet Error 0x00000110: Address not found
ERROR MDNS failed to join multicast group on veth59907d3 for address type IPv4: ../src/inet/UDPEndPointImplSockets.cpp:764: Inet Error 0x00000110: Address not found
ERROR MDNS failed to join multicast group on veth6f9a356 for address type IPv4: ../src/inet/UDPEndPointImplSockets.cpp:764: Inet Error 0x00000110: Address not found
ERROR MDNS failed to join multicast group on veth0537116 for address type IPv4: ../src/inet/UDPEndPointImplSockets.cpp:764: Inet Error 0x00000110: Address not found
ERROR MDNS failed to join multicast group on wpan0 for address type IPv4: ../src/inet/UDPEndPointImplSockets.cpp:764: Inet Error 0x00000110: Address not found
ERROR MDNS failed to join multicast group on veth5aa8df9 for address type IPv4: ../src/inet/UDPEndPointImplSockets.cpp:764: Inet Error 0x00000110: Address not found

What are all these veth-interfaces used to? Does the Matter server really need to access them?

Today in the evening I can disable the two mDNS settings fur testing purposes and restart the Matter server again to look if these MDNS ERRORs go away.

At the moment I can't risk a deactivated Wifi. My wife is working in the home office. 😉

[rancid temple]

huh wait... so the device became unavailable in HA when you pulled the batteries and came back when you re-inserted the battery (but still with the wrong state? OK, now it gets even more strange haha.

I have the door sensor here so if I can get it back to life again I will do some extended tests myself. This almost sounds like we're misreading a value for the device. This is not the same issue as before (where the devices became unavailable) but something totally different, this has nothing to do with networking is my gut feeling. I will let you know as soon as I got the device reinstated

[flint ledge]

Yes, that’s it. The Window was open, battery removed/reinserted, state unavailable, state closed.

So I closed/opened the window, but the state didn’t change.

But the EVE D&W definitely worked after the initial pairing with HA. It changed the state to open and closed at least once a time.

[rancid temple]

Yes, that was also the case in my tests but I believe there has been a firmware update of the device in the meanwhile

s maybe... just maybe.. they changed something ?

anyways, I'm going to test it myself and let you know

[flint ledge]

No, all my devices are up-to-date.

[flint ledge]

Thanks

@rancid temple any idea about the MDNS ERRORs above? What are all these veth interfaces?

[rancid temple]

I mean, since I implemented the door sensor in HA and now. Maybe there has been an update since then.

[rancid temple]

That comes from the lowlevel SDK code, I think it is just being dumb and trying all interfaces one by one. I'll see if I can finetune that but chances are low without having to touch the underlying C code but you'll never know.

[flint ledge]

No need to do this. I was a bit irritated after our mDNS discussion… 😉 But you wrote what I thought. It’s a dumb check of all interfaces. Have a nice evening

[rancid temple]

hahaha! have a nice evening too!

[sonic swift]

@flint ledge just a heads up, eve energy firmware 3.2 has been released

[flint ledge]

Ok, I don’t see a firmware update in the EVE App. I have the European version of the EVE Energy. Anything special to get it?

[sonic swift]

i looked in the home app

and checked for updates

https://imgur.com/a/yEwnDRd

that is what it looked like

[flint ledge]

No, not for me. It says „ Your home and all devices are up-to-date.“ Do you also see firmware updates for the EVE Door & Window and the EVE Motion?

[sonic swift]

Nope. only the eve energy

[flint ledge]

Ok. Maybe it’s a rolling update and I will see it later this day.

[rancid temple]

@flint ledge I was able to reproduce the issue with the door sensor from Eve. Its crashing very low level due to unexpected data. In other words: the device is sending non spec compliant data. Unfortunately the python wrapped sdk code crashes on this and the subscription gets lost because of that. Let's hope the firmware update fixed that or the release of the new sdk (1.1) includes the updated schema. I'll keep an eye on it.

For now: I will update our docs that this device is incompatible with HA for now.

[flint ledge]

@rancid temple Thanks for the interesting information. 🙃

Yes, I also think it’s best to wait for the next firmware update, which should arrive in some days (maybe April 17th?). At least I read this somewhere.

Thanks again

[sonic swift]

From my understanding from communication with eve. 3.2 is the release firmware and you should be able to upgrade to it already (atleast you can through homekit)

not sure how matter accessorys updates are handed over samsumg tho

[rancid temple]

Well, in the meanwhile I couldn't resist and went elbow deep into the low level code and found the root cause for this which is not Eve specific but just for any device that sends manufacturer specific data and that crashes in a very specific condition when the data is sent with other data (burst of value changes)

long story short, I'm going to report/fix this upstream and bake a patch in our code

[sonic swift]

huh, so the work around is dont trigger the sensor/switch when trying to pair it?

[rancid temple]

no, eve devices send multiple devices at once when you trigger it

[sonic swift]

oh rightio. that makes alot more sense now

[rancid temple]

and because the manufacturer specific data could not be read, the rest of the data in the same "burst" gets lost

[flint ledge]

Are you talking about the EVE Door&Window and EVE Morion or the EVE Energy? EVE Energies latest firmware is 3.2. But is it also the case for the other two device types? Apple Home didn’t offer me the firmware update 3.2 for EVE D&W and Motion.

[sonic swift]

eve motion and door/window are still on 3.1

the energy is on 3.2

the motion and door/window are slanted to come out later this week. then the OTA matter update will drop to the public

[flint ledge]

This is what I meant. 😉 I think on Reddit I read April 17th is the release date for the official EVE Matter D&W and Motion. So that should be the least date where we also get the new firmware.

I already have 3.2 on my EVE Energy.

[sonic swift]

Hopefully, the motion sensor has so many bugs atm its not funny lmao

[flint ledge]

Fantastic! 😃 Can you keep us updated? How can we help to test your result?

[rancid temple]

we can just patch the matter add-on for this so you can test.

[sonic swift]

brilliant, would be good to see this get fixed, both for your issue, but also everyone else who will be getting matter from the release on the 17th

[flint ledge]

Ok, great! So my HA instance must be in the beta phase or do I need to compile HA on my own? Never did this with HA. I am really new to HA, since December 2022.

[rancid temple]

No add-ons can be updated separately from HA core

door sensor works now with my patch

motion sensor also works but illuminance level is wrong in the raw data (just 1 lux all the time)

[sonic swift]

Yep, eve has acknowledged it and its fixed in 3.2 (apparently)

[sonic swift]

i would leave the matter add on (should be located here "http://homeassistant.local:8123/hassio/addon/core_matter_server/info"). i would keep it on auto-update and start on boot, as well as keeping the watchdog on

[flint ledge]

Ok, perfect! Now we only need the energy custom characteristics for the EVE Energy. 😂😉

[flint ledge]

This is already the case for me. I didn’t know that add-ons can be updated separately from HA core.

[flint ledge]

Hi guys, wanted to inform you about my current situation.

I have round about 40 EVE devices:

Full Thread Devices (FTD):

• 20 EVE Energy
• 1 EVE Water Guard

Minimal Thread Devices (MTD):

• EVE Door & Window
• EVE Thermo
• EVE Weather
• EVE Room

With the beginning of the beta phase I migrated one of the following types to Matter:

• 1 EVE Energy
• 1 EVE Door & Window
• 1 EVE Motion

Before I started to migrate further devices, I completely removed the EVE Door & Window and the EVE Motion from my Environment, because they are still on firmware 3.1 and not the production firmware 3.2.

I started with the migration of my EVE Energies in my office room. So I had six 6 EVE Energies with Matter firmware. I waited one day. Everything was stable and worked as expected.

Now I decided to migrate the remaining 9 EVE Energies in my house. Migration procedure was smooth. But when I migrated the last EVE Energy, I recognized that my Thread network is completely unstable/unreliable.

I tried a lot of things, like rebooting my Apple Home Hub / Thread Border Router. I have one AppleTV 4K (latest Gen connected via Ethernet). I also waited one day to check if it settles on its own. But nothing helped.

I started to reduce the Matter EVE Energies one after the other in hope to get my stability back.

After every EVE Energy remove, I also removed the current from my AppleTV, waited a bit and started it again to force a new Thread network forming process.

When I was down to 16 FTDs (10 Matter EVE Energies, 5 HomeKit EVE Energies and 1 HomeKit EVE Water Guard) it stabilized immediately.

As soon as I add one additional Matter EVE Energy again, the complete Thread networks get wonky.

Maybe it's just coincidence, but there seems to be a border to have only 16 FTDs at the moment.

This makes me a little curious, because on OpenThread they write the following in the chapter „device limits“:
———————
Thread tries to keep the number of routers between 16 and 23.
———————
Source: https://openthread.io/guides/thread-primer/node-roles-and-types?hl=de#device_limits

My Thread Network is now stable since 3 days.

I was in contact to the EVE support, they told me, that it’s a known behavior for Apple Thread Border Routers, when you have more than 16 FTDs.

It worked fine over months with 21 FTDs, when I had 20 HomeKit EVE FTDs and 1 Matter EVE FTD.

As already said, not a big deal at the moment, because my environment is stable. But I already pre-ordered 20 Nanoleaf Matter bulbs. I think that they are also FTDs. And in this case the first bulb may crash my Thread network. What the heck? 😃

[sonic swift]

It seems to just be early adopter pain for such a new protocol.

Where edge cases like this exist. And it is amplified becuase getting this many companies to work together can be jank, and occasionally things can break

[flint ledge]

Yea, you may be right with the early adopter pain. But why do you think, that this is an edge case? It’s not very hard to get to 16 FTDs.

That’s a bug in my opinion.

[sonic swift]

I feel once we get to a point where we get some user customisation as to what can act as a border router/edge device. At some point this automation of it is good, but having too much and not knowing isn’t good

[flint ledge]

I am not talking about Thread Border Routers. I have the issue with FTDs (Full Thread Devices), Thread Routers (mains powered) for example. Look here:

https://openthread.io/guides/thread-primer/node-roles-and-types?hl=de#device_types

I have only one Thread Border Router, an AppleTV 4K.