Preparing to install ViLocal

[JosefinBerlin]

Dear @kristian ,

with your help I managed to find the network key. Thank you very much for that. Unfortunately, I can't get any further again:
So far, my SMLIGHT SLZB-06MU has been outside of Homeassistant. HA was turned off when sniffing for the network key. If I understand it correctly, my SMLIGHT SLZB-06MU has to be in homeassistant somehow, since ViLocal is supposed to run as a service later. Now I have the understanding problem that I use ZHA in homeassistant, i.e. a ZigBee network (channel 20) with a Home Assistant Connect ZBT-2 as coordinator. However, I can only add the SMLIGHT SLZB-06M to this ZigBee network if it is in router mode and not in coordinator mode, which is necessary for sniffing. Now my question: Will the SMLIGHT SLZB-06M not be inserted into HA at all or do I have to set up a 2nd ZigBee network with the SMLIGHT SLZB-06M as coordinator? I also have Z2M (ZigBee2MQTT) but can't handle it yet.

[kristian]

Dear @JosefinBerlin, glad to help.

No need to overcomplicate things luckily! 👍🏻 There is no need to add your SMLIGHT dongle to HomeAssistant or doing anything similar! If you have been able to sniff the network key, it is already more than half the battle, as ViLocal works essentially exactly the same as ZBTK did.

What you did when sniffing for the network key, is you piped embersniff to zbtk. Now that you have the network key, you just put that into your ViLocal configuration and start ViLocal much the same way, just pupe embersniff into vilocal instead of zbtk and that's all it takes. If you set up the service, with the service file I provided in the readme later on, that will do it for you.

Now, HomeAssistant. ViLocal does not need to be added to your HA instance, neither does your SMLIGHT dongle, so don't worry about coordinator or something else. But sure, you can not use the same SMLIGHT dongle multi purpose. Either use it for ViLocal or connect it to your HA. If you want to do both, you need two dongles.

ViLocal actually isn't connected to HA directly, but via your so called MQTT broker. You need to add the IP and username / password of your MQTT broker into the ViLocal configuration, and the data will automatically appear in HomeAssistant as own entities. This is all described in the README so please read it carefully. Thanks.

[JosefinBerlin]

Hi @kristian,
thanks for the hint. But now it gets difficult for me: I use Homeassistant on a homeassistant green (HA OS 18.0, Core: 2026.6.4), which is known to have certain limitations. The way I see it, I can only get ahead with docker. Correct? Again and again obstacles. I've never done that before. Can you give me code for docker?
Best regards and a nice football match

[JosefinBerlin]

A HA app (add-on) would be great.

[JosefinBerlin]

Hi @kristian,

I have dealt with docker with the help of AI and have created these files in the directory addons/meins/vilocal:
-dockerfile
-start.sh

• .......
  Dockerfile.txt
  start.sh

I'll add the files. If dockerfile.txt remove the extension again.
There are also the folders ember-sniff and zbtk with node_modules in the subdirectory bin.
I now have local Vilocal in the Addon(App) Store and can install it. It starts 😊, but I get the following error:
Start ViLocal...
FIFO: /tmp/vilocal.pipe
Start ember-sniff...
Start ViLocal...
file:///app/bin/ember-sniff/node_modules/ember-zli/dist/utils/ember.js:43
throw new Error('Failed to start EZSP layer with status=${EzspStatus[startResult]}.');
^
Error: Failed to start EZSP layer with status=HOST_FATAL_ERROR.
at emberStart (file:///app/bin/ember-sniff/node_modules/ember-zli/dist/utils/ember.js:43:15)
at async file:///app/bin/ember-sniff/index.js:43:14
Node.js v24.18.0

Now the AI is on strike and wants to talk me into a new stick. Since you also used the SLZB-06MU, I wonder how you get along with the SLZB-06MU in homeassistant. I don't have ZigBee2MQTT. I can't do without ZHA. There are already 17 devices there and more are being added.
Best regards,

[kristian]

Sorry @JosefinBerlin, I will not be able to help you with some mess the AI created. This creates more effort for me than anything else. Please wait for me to publish ViLocal as an HA app, or follow the instructions provided and install it on a RaspberryPi manually.

[JosefinBerlin]

I think so. I will wait

[kristian]

Have you already tried or succeeded setting up ViLocal with the Home Assistant App @JosefinBerlin?

https://github.com/kristian/ViLocal-ha_app

[kristian]

ViLocal is now available as Home Assistant App version! 💯 Feel free to check it out:

https://github.com/kristian/ViLocal-ha_app

[JosefinBerlin]

@PiiCii58 : Firmware-Revision: 20250220

[PiiCii58]

Update: test with a second SLZB-06MU

I received a new SLZB-06MU today and have been testing it for several hours.

Adapter #1 used 192.168.168.106; the new adapter #2 uses 192.168.168.108. The attached log contains some older entries from #1, followed by several hours of operation with #2.

The good news is that the ViLocal HA app itself has remained operational for several hours and recovery/restarts appear to work much better with adapter #2.

However, the underlying ASH problem is still present.

In the log section for adapter #2 I find approximately:

• 47 × ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT
• 47 × ASH_NCP_FATAL_ERROR
• 6 × ERROR_SERIAL_INIT
• 51 log messages mentioning run out of buffers
• about 3,758 × Packet encrypted / decryption failed or not attempted
• 54 successful subsequent ASH connected / EZSP started sequences.

The fatal errors still consistently show:

ASH disconnected | Adapter status: ASH_NCP_FATAL_ERROR
Fatal error, status=ASH_NCP_FATAL_ERROR.
Last Frame: [FRAME: ID=138:"MFGLIB_INTERNAL_SET_CHANNEL" Seq=5 Len=9]

After most failures, ember-sniff successfully reconnects and starts ASH/EZSP again. In a few cases recovery first fails with ERROR_SERIAL_INIT, followed by a later successful start.

This appears to rule out an individual hardware defect of adapter #1 as the primary cause of the ASH failures, since a second SLZB-06MU shows essentially the same ASH behaviour.

There also seems to be substantial additional traffic on Zigbee channel 20. The large number of packets which cannot be decrypted may be consistent with the previously suspected second Zigbee network on channel 20.

Two questions therefore came to my mind:

1. Could the additional channel-20 traffic contribute to the run out of buffers condition and eventually to the ASH ACK timeout?
2. After ASH_NCP_FATAL_ERROR, is the NCP/ASH state fully reset before ember-sniff reconnects? The occasional ERROR_SERIAL_INIT during recovery made me wonder whether the restart may sometimes happen while the adapter/NCP is not yet completely ready.

One additional hardware observation: adapter #1 behaved differently during a factory-reset test. Its LEDs remained off while/after holding the reset button, whereas adapter #2 behaves normally and the LEDs come back on after releasing the button. So #1 may still have an unrelated hardware/reset issue, but the ASH failure itself is reproducible with both adapters.

[kristian]

Thanks for your update. Interesting observations @PiiCii58 and sorry to hear about all the troubles ViLocal has given you so far. Sniffing is quite a heavy operation on the sticks, this is also why sniffing via WiFi is generally not sustainable and sniffing essentially demands a stable connection via ethernet. Having thousands of decryption faults is definitely nothing I have seen in any other installation yet and I would agree to your understanding, that there is serious other traffic on your channel 20. As far as I know sniffing on the dongles is stateless, however, if it is some proprietary ZigBee stuff, it could explain the faults and throwing the adaper out of wack most definitely. Strangely enough, there should be plenty of channels in ZigBee and if all vendors would follow the ZigBee spec. your coordinator should even try to find a less congested channel, if it notices so much third party traffic. Unfortunately many devices (including Viessmann) do not implement such a channel fallback and cheaped out on their ZigBee implementation. Depending on the implementation they will only scan for ZigBee channels once when set-up, or even worse, cheaper devices will just choose a random channel once, making conflicts like this a 1 in 16 chance unfortunately. Long story short: Yes, as you now have tried multiple adapters and the rest of your setup is similar to many other ViLocal users, my only guess what causes the problems is the congestion on the network caused by the 3rd party. Unfortunately the only way to force Vitcoconnect to choose a new ZigBee channel is to reset it and re-pair all the devices. Would be a super intersting experiment (also for future users of ViCare having the same issue), but that is definitely a bigger task to tackle and involves quite a lot of effort. I‘d be intested hearing from any new discoveries!

[JosefinBerlin]

Hi @PiiCii58 ,

if you still have problems with your SLZB-06MU try the support of SMLIGHT:
https://support-legacy.smlight.tech/supportcenter/public/en/
The support is really great and has also helped me.

[PiiCii58]

Hello @JosefinBerlin,
Thanks for asking. Yes, even with a new SLZB-06MU I cannot run Vilocal stable. Same error messages like the first adapter but more seldom.
I am currently busy with another Homeassistant project which I want to follow up first (climate manager for aircondition 😊).
In the context of Vilocal I intend to try finding another channel. That means disable all my Vicare devices and newly start sniffing with the Gateway and one only thermostat.
I changed a few weeks ago my heating system away from Viessmann. Nevertheless I intend to use the Vicare thermostats for room temperature (in winter time).
I will report on what I am doing for my Vilocal integration.

[JosefinBerlin]

f62e2e4d_vilocal_2026-07-21T09-29-20.382Z.log
Right?

[JosefinBerlin]

In this Moment (after restart HA) I see new information:
Received attributes from unknown climate sensor with serial number "14-2D-41-FF-FE-79-72-61". Consider adding it to the "local_config.toml" file to provide a better device discovery record. Device will not be published, as "publish_unknown_devices" is set to "false".

[kristian]

That sounds very promising @JosefinBerlin, that already confirms so many things! :)

1. Data is received by the app
2. Data is successfully decrypted (which is even more important)
3. Data WOULD be parsed / injected, if it would be known

So then, your task can be to add your remaining serial numbers in the app UI and just wait if data will appear! 👍

[kristian]

f62e2e4d_vilocal_2026-07-21T09-29-20.382Z.log Right?

And just to confirm, yes this log looks as it should be! So you can finally disable -vvv and verbose logging 👍 It is no longer needed. My best guess is: It works now! 👍

[JosefinBerlin]

Yuhuu, I get the informations humidity and temperature👍👍👍👏👏🚀🚀, but not battery level.

[JosefinBerlin]

[kristian]

Some information is not sent as frequently as others. Battery level for example is only send every 6 hours. So just keep it running and you will see all values at some point in time! 👍 Glad we could finally figure this out and happy to have you as a new user of ViLocal @JosefinBerlin 👍

[JosefinBerlin]

Thanks a lot for your great help and for your patience.

[PiiCii58]

Hi @JosefinBerlin and @kristian, I am using the same dongle SLZB-06MU via POE updated to the most recent firmware versions v3.5.5.dev1 as Zigbee Coordinator v20250220. I did not change any dongle settings since delivery. Sniffing for transport key was successful using the terminal app of my MacBook (2 days ago).
I installed Vilocal 1.4 in HA on a Raspi 5 and I am using the HA MQTT broker integration in HA.
The Vilocal configuration went well and all thermostats and climate sensors got values in HA (MQTT integration).
Unfortunately Vilocal hangs up while getting ASH problems.
Any ideas?

[kristian]

Hello @PiiCii58, have you remove / can you try to disable the same parameter that @JosefinBerlin did? "Enable processing of Zigbee socket packets" should be off, as far as Josef found out.

#3 (reply in thread)

[PiiCii58]

It is disabled (by default).

[PiiCii58]

Hi Kristian,The setting is disabled by default. So yes, it is off.Sorry, I did not find back what I wrote in the thread.PeterVon meinem iPad gesendetAm 04.08.2026 um 14:13 schrieb Kristian Kraljic ***@***.***>: Hello @PiiCii58, have you remove / can you try to disable the same parameter that @JosefinBerlin did? "Enable processing of Zigbee socket packets" should be off, as far as Josef found out. #3 (reply in thread) —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>