mirror of
https://github.com/lox-audioserver/lox-audioserver.git
synced 2026-04-26 06:45:47 +03:00
[GH-ISSUE #115] 4.x branch - bell dont work #62
Labels
No labels
bug
enhancement
pull-request
released
released on @beta
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/lox-audioserver#62
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Re4DeR on GitHub (Jan 11, 2026).
Original GitHub issue: https://github.com/lox-audioserver/lox-audioserver/issues/115
Hi,
in last 4.x-branch doesn't work Bell for me.
lox setup is jsut pushbutton to bell input
lox-audioserver log:
[2026-01-11T18:55:27.994Z][INFO][Alerts|Manager] [type=bell zones=[5]] ON alert [2026-01-11T18:55:27.994Z][INFO][Audio|Manager] [hasStream=false label=alerts://bell.mp3 sourceKind=file zoneId=5] startWithResolvedSource [2026-01-11T18:55:27.994Z][INFO][Audio|Manager] [handoff=false kind=file profiles=["pcm"] zoneId=5] starting audio engine [2026-01-11T18:55:27.994Z][INFO][Audio|Session] [maxBufferBytes=262144 outputBitDepth=16 outputChannels=2 outputSampleRate=48000 profile=pcm targetLeadMs=1000 zoneId=5] audio session buffer config [2026-01-11T18:55:27.999Z][INFO][Audio|Engine] [profile=pcm source=file zoneId=5] audio session started [2026-01-11T18:55:27.999Z][INFO][Audio|Manager] [source=alerts://bell.mp3 stream=5-b730c862-e596-4bc1-84c0-0f9e76499162 title=bell zoneId=5] playback started [2026-01-11T18:55:27.999Z][INFO][Http|Snapcast] [clientId=snapclient-pracovna streamId=5] snapcast client reassigned to stream [2026-01-11T18:55:27.999Z][INFO][Http|Snapcast] [bitDepth=16 channels=2 clientIds=["snapclient-pracovna"] sampleRate=48000 streamId=5 zoneId=5] snapcast stream registered [2026-01-11T18:55:28.008Z][INFO][Audio|Session] [bytes=14276 profile=pcm zoneId=5] ffmpeg first chunk [2026-01-11T18:55:29.707Z][INFO][Audio|Session] [bufferedBytes=262144 code=0 earlyExit=false runMs=1712 signal=null stderr=undefined stderrAt=undefined subscribers=1 totalBytes=2467072 zoneId=5] ffmpeg exited [2026-01-11T18:55:29.707Z][WARN][Audio|Manager] [source=alerts://bell.mp3 zoneId=5] playback session terminated by engineclient is snap.
Music playback works correctly. Triggering the bell pauses and resumes the music, but the bell itself is silent.
@rudyberends commented on GitHub (Jan 11, 2026):
Yes, I need to look into this. Technically everything is working as expected, but this is most likely a latency/buffering problem in the current audio engine.
The bell is correctly started, decoded, and streamed (which is clearly visible in the logs), but the audio file is so short that it finishes before the client actually starts playing audio. The client needs some time to fill its buffer before output begins. As a result, nothing is heard, even though the music is correctly paused and resumed.
This can be easily demonstrated:
• If you use a longer audio file (for example an mp3 song), the bell does play correctly.
I will come back on this one
@wiking-at commented on GitHub (Jan 13, 2026):
I also managed to get the Lox Audio Server up and running and used a SendSpin client for testing (setup: https://gist.github.com/wiking-at/d7789afb9107c3f6a16501e1914bbe41
). When playing announcements or text-to-speech messages, the first few seconds of the audio are not reproduced correctly. Due to interference at the beginning, the spoken content is initially difficult to understand, but the playback quality improves afterward. Additionally, the doorbell audio has a delay of approximately 6 seconds compared to the optical doorbell in Loxone that triggers the light.
@mr-manuel commented on GitHub (Jan 14, 2026):
@Re4DeR this is not how it's designed by Loxone. I already requested to improve the documentation on that on their website.
I'm currently testing the 4.x branch with a SnapCast client on Debian 13. All of the inputs (
Alarm,FireAlarm,Bell,Buzzer,TTS) do not work at all.When they worked, they also did not work as they should: https://github.com/rudyberends/lox-audioserver/issues/29#issuecomment-3395279984
I'm on
github.com/rudyberends/lox-audioserver@1f1965b641(up-to-date 4.x branch).Probably this is all the same issue. It would be interesting how it behaves with SqueezeLite clients that are directly connected in Lox Audio Server.
@Re4DeR commented on GitHub (Jan 14, 2026):
what is wrong? how it should be?
@mr-manuel commented on GitHub (Jan 14, 2026):
It should play only as long as the input is on 1. That is how the original Audio Server works. See also my previous comment.
@Re4DeR commented on GitHub (Jan 14, 2026):
I see. Usually it is controlled through the https://www.loxone.com/enen/kb/door-controller/ and maxB
@rudyberends commented on GitHub (Jan 18, 2026):
This is not the same issue. The problem you saw was specific to 4.x and its new audio engine. It was a buffering problem, and it is fixed in the latest beta.
The issue you’re referring to existed in 3.x and has never been present in 4.x. Because of the 4.x buffering problem, you were effectively prevented from testing this properly until now.
The Audioserver supports two alert behaviors:
1. One-shot alert (normal file)
Example: doorbell.
This is simply played once and then ends. This should work fine now.
2. Looped alert
This is implemented correctly from an Audioserver perspective, but it works differently from a one-shot.
A looped alert is started like this:
• /audio/grouped/alarm/27
This starts the loop and it will continue indefinitely until it is explicitly stopped via an off/stop command:
• /audio/grouped/alarm/off/27
• /audio/grouped/alarm/stop/27 (I believe this is what Loxone uses)
Important detail: the Audioserver has no knowledge of the Function Block input state. It only reacts to HTTP commands. It’s the Miniserver’s responsibility to send the corresponding stop command when the input goes back to 0.
@Re4DeR commented on GitHub (Jan 18, 2026):
for me bell is working now in beta. I am going to test it more tomorrow.
@Re4DeR commented on GitHub (Jan 18, 2026):
Just one problem maybe. Bell dont use Vbell parametr. Volume stays same
@wiking-at commented on GitHub (Jan 18, 2026):
I also tested TTS - works for me now with beta.
I still got an issue when using spotify connect using the internal player of a zone. i can select the lox-audioserver zone output - but music never gets played. funny thing is - if i play a radio stream and stop it before trying spotify connect i can start/stop the radio stream in the spotify app again (while trying to start/stop spotify content). i use a sendspin zone. do you want me to create a more detailed issue? or is spotify connect WIP currently in beta and it is to early to create issues for this feature?
@rudyberends commented on GitHub (Jan 19, 2026):
Should be fixed with this
d629728@rudyberends commented on GitHub (Jan 20, 2026):
We can have a look at it, but please open a separate issue for this
@wiking-at commented on GitHub (Jan 23, 2026):
ok - i wait for the next beta build as there are some sendspin fixes which are not reflected in the current beta build. if the issues persist i will open a dedicated issue.
@mr-manuel commented on GitHub (Jan 25, 2026):
I now tested
github.com/rudyberends/lox-audioserver@63e7b72111but unfortunately it does not work as it should and described in: https://github.com/rudyberends/lox-audioserver/issues/115#issuecomment-3748955569It should have the same behavior as the original audio server.
Once an Alarm or FireAlarm is triggered it does not stop to play. I tried with constant
1on the input, but also only with a pulse. --> Wrong behaviorOnce a Bell or Buzzer is triggered it does only play once. I tried with constant
1on the input, but also only with a pulse. --> Wrong behavior@rudyberends commented on GitHub (Jan 25, 2026):
I really do get your point, but I don't think you got mine 😅
I fully understand how this is supposed to work. Looped alerts (alarm, fire alarm) are meant to play as long as they are “on”, and that is exactly how this is implemented.
For example an alert on zone 27, the Miniserver starts the alert with:
/audio/grouped/alarm/27This turns the alarm on and it will keep playing on a loop indefinitely.
To stop the alert, the Audioserver expects an explicit stop command:
/audio/grouped/alarm/stop/27This immediately stops the playback.
You can easily verify this behavior using a browser or a tool like Postman.
HOWEVER, what seems to be happening here is that the Miniserver only sends the ON command and never sends the corresponding STOP command. That is exactly what you are seeing.
As mentioned before, the Audioserver has no knowledge of the Function Block input state. It only reacts to incoming HTTP commands. It is entirely the Miniserver’s responsibility to inform the audioserver when the input goes back to 0.
Unless I am missing something, there is simply no other command being sent to the Audioserver that would allow it to stop looped playback automatically. That makes it impossible to implement the behavior you are requesting purely on the Audioserver side.
We could technically solve this by connecting to the Miniserver ourselves, authenticate, subscribing to block states, and stopping playback when inputs change. But I strongly dislike that approach:
• it requires Miniserver credentials,
• additional configuration to select which blocks to monitor,
• and it introduces logic that clearly does not belong in an Audioserver.
Another workaround could be in loxone config to act on the function block with a virtual output command and send the OFF command like that. However if a real audio server works, we should be able to replicate that behavior.
We are most likely missing something here. There must be a mechanism by which the Miniserver informs the Audioserver to stop looped playback. It is really strange that it does send a http/ws ON, but never sends STOP.
If you can figure out what that mechanism is, we can absolutely take another look at it. But “it should play as long as the function block is on” is not the answer I’m looking for.
I hope this clarifies the issue.
@mr-manuel commented on GitHub (Jan 25, 2026):
Thanks for clarification. It can easily be a bug in the current Miniserver implementation of Loxone. I will check this directly with the Loxone developer which is responsible for this API. Since this may take a while, please leave this issue open.
@mr-manuel commented on GitHub (Jan 25, 2026):
Do you have a link to the protocol documentation of the Loxone audio server or did you all reverse engineering it?
@rudyberends commented on GitHub (Jan 25, 2026):
It might indeed be a bug. However this was already the case with the earliest 3.x builds, so I cannot imagine they would have not fixed it by now. @simon2207 will be able to tell, as he has real hardware to validate against.
Unlike the Miniserver API (which is really well documented and encourages development), the Audioserver API is not publicly documented. They probably also dont want it to be known and used other than by their own hardware. This codebase is probably the best reference available for the protocol specification.
The protocol itself is not that hard to reverse-engineer. You can observe the WebSocket communication between the Loxone app and the Audioserver using a browser’s developer tools.
Another option is to run your own web server and configure the Miniserver to use it as an Audioserver. This allows you to see every request the Miniserver or app sends. It's basically how this code started. Just log all requests, reply with empty responses and implement them one by one. Their online demo environments allow you to see the expected responses.
Additionally, all Loxone apps are Electron-based, meaning they are essentially web applications running inside an embedded browser. You can extract the application (android and mac are easiest) packages and inspect the source code. It is heavily minified, which makes it really hard to interpret. That said, I have a strong feeling that Spotify will not remain the only native streaming service they provide for very long. 😉
@simon2207 commented on GitHub (Jan 25, 2026):
@rudyberends What am I able to test? I went through this thread but I don't get problem.
@mr-manuel commented on GitHub (Jan 25, 2026):
@simon2207 on the original Audio Server play any song, then set Alarm to
1. Wait a few seconds, then set Alarm to0. Does the alarm stop and the song proceed to play? Test the same with no song playing and check if the alarm stops, when the input goes from1to0.Here a simple sample on how you can test it:
@simon2207 commented on GitHub (Jan 26, 2026):
@mr-manuel @rudyberends
Good Morning Winter Wonderland... ;-)
Could confirm:
Orignal Audioserver - attached Stereo Extension - 1 Zone for Testing
Play Status shows ON while playing Music / Bell / Alarm - showed OFF during silent phases.
@rudyberends commented on GitHub (Jan 31, 2026):
Thank you for testing. So we can conclude this is not a bug.
For now, this is not something I will pursue further, as I don’t have a clear path to a fix. I did some additional testing, and you can already see in Loxone Config that when you turn (for example) the alarm off, the input switches to OFF, but the output (AR) stays ON. That also suggests there is another (currently unknown) mechanism involved. I used packet captures to see if anything is sent from the Miniserver to stop a looped event, but there isn’t a single byte sent.
Also, when you stop the fire alarm via the app (not by flipping a switch, but by confirming the actual alarm), the OFF command is sent to the audioserver, resulting in a stop.
If anyone can discover this method and explain it to me, I will fix the issues with the looped events.
For now I will leave the doorbell a one shot event, as making this looped will make it unusable for everyone, because the bell will then never stop.
@Ja-Ju commented on GitHub (Feb 2, 2026):
Hello @rudyberends
I'm not sure, if it is a new finding, so I post it here.
Because a regular bell was forgotten in our house, I try to make it work on my google home speakers with your project. Thank you already here that you help so many people out!
I configured music assistant and lox-audioserver. It was really easy to connect it to the miniserver. Two zones were detected and I connected the two nest home and nest mini via IP (they were not found automatically).
If I ring the bell now, I can see that volume gets adjusted and hear the cast-sound on the speakers. Like when I start casting from the phone and the speaker turns itself on. Unfortunately the most important is not happening: the bell sound doesn't appear. Is there something I can do to fix it or is there an open issue with google home speakers?
I also realized, that the loxone app always says "retrieving data..." on the music tile. Is this normal?
If I go to music assistant and start playback on the automatically detected lox-zone it works and starts the song, but if I pause and resume, the track starts from the beginning - maybe an issue in music assistant, not in lox-audioserver.
Many questions in here. Thanks in advance for your answer!
(I read your posts and can open for each finding another issue, if needed)
@mr-manuel commented on GitHub (Feb 5, 2026):
Now I got a feedback from the developer.
Alarm,FireAlarmandBuzzerplay as overlay as long the input is on1.BellandTTSplay as overlay if they get a short trigger.I opened an issue on Loxone side to check the stop command.
@rudyberends commented on GitHub (Feb 7, 2026):
I will fix the bell for cast devices. This is very specific to the cast protocol and I can reproduce it. It will be fixed in the next beta. Please open another issue for your other problem.
@Ja-Ju commented on GitHub (Feb 8, 2026):
Hello @rudyberends
I tried the new version right away. The first time I pushed the bell button, I heard a bell sound very quiet. I had the "minimum volume doorbell" on 60 in loxone. I adjusted it to 100, but now when I click, it doesn't ring again. The speakers stay silent.
@rudyberends commented on GitHub (Feb 8, 2026):
Could you show me the logs of a bell action?
I can’t reproduce this anymore on the latest builds. In beta4 there was a bug where the bell action could fail specifically on Google Cast outputs. This should be resolved in beta5.
To verify, I run an automated stress test that triggers the bell event 50 times while the system is under heavy load. With beta5 every single trigger is audible and completes successfully.
For google cast devices you can also use sendspin or snapcast. Depending on the device, this might work better than plain google cast
@Ja-Ju commented on GitHub (Feb 8, 2026):
Hello @rudyberends
This is the log, after I pushed the button. The speaker didn't even make a sound or switched the light on.
Not sure how to use senspin or snapcast. On both it says "0 devices discovered". Even on Google Cast I have to enter the IP manually as it gets not discovered automatically.
@rudyberends commented on GitHub (Feb 8, 2026):
What i can tell from the log:
The alert itself is being played correctly inside the server: ffmpeg starts, produces audio (ffmpeg first chunk), and exits cleanly.
But for both zones (zoneId=1 and zoneId=2) the session ends with subscribers=0.
That means no output subscribed to the playback session, so the server never actually streamed the alert to any speaker. Result: no sound, no “speaker wake”, nothing.
If you’re running this in a Docker container without network_mode: host, it’s very common that mDNS/Bonjour discovery won’t work (so “0 devices discovered” is expected). That’s a container networking limitation, not necessarily missing devices.
Manual IP configuration can still work, but only if:
The output is truly assigned to the zone (zone output / transports mapping).
The required ports are reachable from the device (especially for Google Cast: the Cast device must be able to fetch http://audioserver-ip:7090/... from the server).
What I need you to provide so we can pinpoint the issue:
2.Zone/output routing for the zones that should ring
Output of:
curl -s http://audioserver-ip:7090/admin/api/zones/states(Only include the entries for zone 1 and 2, or whichever zones should actually play the alert.)
Once I have those, I can tell whether this is “outputs not assigned to the alert zones” vs “Docker networking/ports prevent the device from reaching the stream” vs “Cast/AirPlay connection issue.”
@Ja-Ju commented on GitHub (Feb 8, 2026):
To add "network_mode: host" did the trick for the automatic discovery. Unfortunately the rest stays the same.
After that I had to change the port of portainer (9000) because the container was not starting.
I played around with all three options but still don't get it to work. I got it ones played but no matter what I do or change the config, it is not playing again.
loxoneaudioserver:
container_name: lox-audioserver
image: ghcr.io/lox-audioserver/lox-audioserver:beta
hostname: lox-audioserver
build:
context: .
dockerfile: ./Dockerfile
restart: always
ports:
- 7090:7090
- 7091:7091
- 7095:7095
network_mode: host
volumes:
- ./lox-audioserver-data:/app/data
curl -s http://192.168.10.11:7090/admin/api/zones/states
{"zones":[{"id":2,"name":"Eingang","title":"Music Assistant","artist":"","album":"","sourceName":"022CA96CE7AE","station":"","state":"stop","coverurl":"","coverUrl":"","updatedAt":1770569777004},{"id":1,"name":"Wohnzimmer & Küche","title":"Music Assistant","artist":"","album":"","sourceName":"022CA96CE7AE","station":"","state":"stop","coverurl":"","coverUrl":"","updatedAt":1770569777004}],"system":{"now":1770569777004,"loadavg":[0.1,0.09,0.08],"uptimeSec":3855,"clockOffsetMs":null,"cores":4}}
@Ja-Ju commented on GitHub (Feb 15, 2026):
Hello @rudyberends
I tried it with the newest beta6.
First with the two google speakers added as google cast devices. Just to mention what exactly happend:
Now this is the log with nothing happening:
Now I changed the output to snapcast. Pressed the bell - nothing happens.
Now I changed the output to sendspin. I pressed the bell - nothing happens. This is the log:
Maybe this helps you to analyze the behavior.
Best regards,
Jakob
@rudyberends commented on GitHub (Feb 15, 2026):
There are no changes regarding this in the latest beta. I will look at it for the next release
@Ja-Ju commented on GitHub (Feb 18, 2026):
Hello @rudyberends
all right! Here the log where it works the first time but not the second:
@rudyberends commented on GitHub (Feb 18, 2026):
This is already fixed in 4728fa9. It will be included in the next beta
@Ja-Ju commented on GitHub (Feb 18, 2026):
Great, can't wait!
@Ja-Ju commented on GitHub (Feb 22, 2026):
Hello @rudyberends
I tried it with the new version, but unfortunately it still doesn't work.
Native google cast plays the bell sound once but not a second time. Sendspin even doesn't play the sound once anymore.
@mr-manuel commented on GitHub (Feb 23, 2026):
On a freshly started system everything works. Seems like somewhere the system get stuck. Did not found yet what exactly is the cause.
What I noted on the overlay playbacks is, that if a song is previously playing the song starts from beginning again instead of resuming it where it stopped. There are still a few glitches in playback, but they are handled in different topics.
I made my tests with a sendspin client.
@rudyberends commented on GitHub (Feb 23, 2026):
i will need a full spam log for this that clearly shows multiple bell attempts. I cannot reproduce this myself
@p4co86 commented on GitHub (Feb 23, 2026):
Bell is working very well for me using squeezelite, YFI