I’m really interested in this !
Do you have some resources about this ?
In exchange, I can share some informations about audio sink in openhab : @mhilbush an audiosink is the other way around : openHAB send audio data to the device.
It seems that the doorbird API has the audio-transmit.cgi path to do this.
It is, as you said it, a u-law codec. I’m not completely sure about this, but I think it’s possible to convert sound file to this codec without much hassle.
I would like to look into it, it seems interesting, but I have a big todo list, so I put an additional information here in case someone is interested and faster than me :
As I made the pulseaudio audio sink, I was confronted to similar conversion difficulty. Here is the conversion code I did (stream to stream)
Changing the TARGET_FORMAT should, maybe, be sufficient ?
Ah, right. I was thinking about it in terms of the Doorbird being an audio source (via audio-receive.cgi). But, yes, it’s the transmit one that would be for a sink.
Hmm. It does look like javax.sound might do the trick. And your pulseaudio implementation looks to be the same stream-to-stream conversion approach that would be needed here.
Yes, me too at the moment.
In the meantime, as a PoC, I suppose someone could try using ffmpeg and curlhttpsink from the command line to prove you can stream some WAV or MP3 content to the Doorbird.
Here’s a link to a guide on how to set up facial recognition in Zoneminder. Though I should add that this system recognises that there is a face in the camera’s view, it doesn’t recognise specific faces. I.e. it can see a that there is a face, not specificially Bill’s face or Sarah’s face.
I have read at least one other guide on how to train systems to recognise particular faces but I don’t have the links to hand at the moment. I’ll have another search later.
The Google Coral TPU can be used to accelerate the image processing and is far faster and more energy efficient than using the CPU.
Even if I should have not (so many things to do !), I did not resist and I did have a look to this audio sink idea.
Aaaaannnd, I failed miserabily, near the end. I send ULAW audio to the doorbird endpoint, and the doorbird device respond with a HTTP 200. But to no avail : no sound.
The result of my work is here, if someone want to check.
I am sorry, but short of idea to make it work !
If only I could have more information from the doorbird. Do we have a way to get more information from it (log maybe?) ?
Thanks for trying this. Unfortunately, I don’t know enough to be able to check what you’ve done. It looks right, but there may be some details about the ulaw stream that might prevent the Doorbird from processing the audio stream.
I’m not aware of any logs that can be pulled from the device.
as mentioned some month ago, there are some channels shown as NULL for my doorbird devices. Especially the channels of Doorbrid Controller A1081 are all three not reachable, what should be my next project.
I tried a few basic things (re-add channels / thing, restart Controller, restart OH3, …) but still the same.
I set doorbird binding to DEBUG and started with activating one of the relay in the doorbird app. But as there is no action detected in OH since the item is NULL, there was no entry in the log file at all (like expected).
I then deleted the Controller thing an re-added it. There are those 2 lines in the log file:
Additionally there is the following entry (not sure whether it comes from creating an item or activating in Doorbird app):
2022-02-13 19:56:12.009 [DEBUG] [d.internal.handler.ControllerHandler] - Got command REFRESH for channel doorbird:a1081:DoorbirdController:openDoor1 of thing doorbird:a1081:DoorbirdController
I don’t see any hint why the channels are not working. Any advice from your side?
P.S.:
IP address and user/pwd in Controller thing’s configuration are from the doorbell not the controller. The mentioned user has all permissions for the Controller, I’ve double-checked that.
As I understand the Doorbird API, if a relay is activated through the Doorbird app, there’s no feedback of that action through the API. So it’s not possible for the binding to know about any relay activations made through the app.
Ok, puh. That is an explanation why I don’t get any response. Thank you for this information. But that means the Controller thing is completely whithout function or is there anything which could be done in OH with it?
Were you able to figure out the work around example? The API documentation for the door bird has said that http commands for keypad events have been coming soon…for the last 2 or so years at least. My understanding is that the only way to get them is through udp.
On Node-RED it can look like this. The sample shows a http get node, which is direktly linked to a switch item through “node-red-contrib-openhab2”. The msg node is only for debugging:
(Yes, in principle gstreamer should be able to do the conversion itself, but I just couldn’t get this to work, and ffmpeg is so fast we lose nothing from the extra step)
interestingly that doesn’t work for me - gstreamer thinks it sent the file, but the doorbird plays clicks/corrupted noises.
I should have added that my solution isn’t perfect - you get clicks every half second or so whilst the audio is playing. But it is intelligible, which is something!
This does not have any clicking sound for me. It just needs a short time until the sound starts.
By the way, I am using an older GStreamer version, but it should not make a difference (1.14.5)