More than one digit codes possible?

[EnerGeh]

Hey, I found your project in the HA forums and it works out of the box for my use case. Thank you very much for your effort on making DTMF call tones usable in HA, this was another missing piece in my home automation paradise. :-) Unfortunately, I'm not able to enter codes that are longer than one digit, that limits me to only 12 (1...9|*|#) possible codes but much more interesting: It could be used as a kind of "pin code" detection and offer endless possibilities with SIP and DTMF. :-) Are you planning to implement this feature or is it possible to extend the digit detection to more digits and I simply missed the according configuration option? Give me a hint if I can help you out on this.

[arnonym]

Hi EnerGeh,

thanks for the feedback!

I see two use-cases in your issue, which would be

1. Add a PIN protection to a menu
2. Have menu entries consisting of more than one digit.

The reason I would not misuse 2 to achieve 1 is, that you would probably like to be told as soon as possible that the menu entry you've entered does not exist. If you do that with a PIN code, it's much easier to brute-force that.

Would you still need 2 if you have 1? We would need to add some validation for this, because having an entry with "1" and another with "10" would be impossible.

[EnerGeh]

Okay, I got your point. I never thought about the voice messages and especially about something like "invalid input". What I dream of is some kind of "DTMF to digit converter", but this is very unlikely your target with this integration. In General the PIN protected menu sounds good, maybe there is some broader integration possible to fit my needs. E.g. like a top menu protection "Enter pin", where the only submenu entry is "start ha action" and that one is triggerd directly after PIN input (configurable at best). A more than one digit menu then sounds as a nice to have. It is very unlikely that you will listen to a voice message with more than 12 options 😉

Edit: I'd be very happy to discuss this further as well as helping to realize whatever you think.

[arnonym]

Would that be triggered by a human or a machine in your use-case?

[EnerGeh]

Do you mean the PIN entry? That would be triggered by humans via a kind of keypad. So there has to be a error handling when someone enters the wrong pin. But when I try to describe this use case more detailed, I feel more that I definetly like to have a converter that simply writes the DTMF digits into a variable so that I can work independently with this way of input. Even the voice part in these calls is not really needed and so maybe I misused your integration according its intention?!

[arnonym]

I'm still not sure what you want to accomplish. If you have the entered keys in a variable inside of the add-on, what would happen next? Probably you would need to feed that string back to home assistant somehow?

What would the error handling on a wrongly entered PIN would look like, if there is no sound output on the input device?

The intention of ha-sip was to solve a very specific use-case of mine, but I tried to keep it as flexible as possible for other use-cases. Currently I do not understand your use-case completely, so hard to say if there is a mismatch.

[arnonym]

Is this still something you want to discuss?

[EnerGeh]

Oh, I feel so sorry, I missed your last reply. Yes of course I'd like to discuss this further. As far as I understand your use case: You're using the menu in a kind of a "intelligent voice routing" (IVR) solution to accomplish stuff like "Press 1 to turn on the light, press 2 to open cover, press 3 to active sound system". This is a very cool idea, but I'd like to use it as a more secure solution for the pin entry at my door access system: Currently, the access code is processed inside the door station and then the "access granted" or "access denied" output is triggered. What I'd prefer is: The door station triggers "someone asks for access" (this is configurable in the door station) and then, HA should call that door station, the call is picked up automatically (configurable in the door station), maybe a voice command announces "Please enter your access code", then the user can enter its PIN via DTMF. This PIN could then be used in HA to accomplish: "User with limited access", "Access prohibited", "Access granted but logged", "Family access, disarm camera surveillance" and unlimited other use cases. Maybe I was more clear in my description now? Sorry for being that unspecific in the last posts.

[arnonym]

Yes, that's much clearer. I came up with the following;

service: hassio.addon_stdin
data_template:
  addon: c7744bff_ha-sip
  input:
    command: dial
    number: sip:**620@fritz.box
    menu:
      message: Please enter your access code
      protected:
        error_message: No.
        pins:
          '12345':
            id: owner
            message: Welcome beautiful.
          '45678':
            id: limited
            message: Please put the parcel under the doormat.
          '98765':
            id: logged
            message: Your access has been logged. 

After entering the correct PIN the Id would be sent to a webhook so you can react on that in home assistant.

Would that solve your use-case? I actually like the idea of having multiple PINs, so you know who leaked the PIN or entered the building.

[arnonym]

I noticed that the pin section is very similar on what we have with choices, so I had another idea:

service: hassio.addon_stdin
data_template:
  addon: c7744bff_ha-sip
  input:
    command: dial
    number: sip:**620@fritz.box
    menu:
      id: main
      message: Please enter your access code
      error_message: No.
      choices_are_pin: true
      choices:
        '12345':
          id: owner
          message: Welcome beautiful.
        '45678':
          id: limited
          message: Please put the parcel under the doormat.
        '98765':
          id: logged
          message: Your access has been logged. 

I like that a bit better, because it does not introduce that special protected section.

What do you think?

[EnerGeh]

Both solutions are looking promising to me, where the second proposal seems to be more straight-forward and comparable to the current YAML configuration of the IVR menu. Did I get that right that both are blueprint proposals and you'd have to adjust the current source code to implement this? The error_message: no option will prevent a "wrong input" announcement to the user in case the pin is incorrect or does it prevent the early trigger of "wrong input" if you dail a digit that is not used in a pin, e.g. pressing 2 while the allowed pin starts with 1, 3 or 9 as you mentioned earlier? What happens if you trigger the right code? I assume you will hear the message and the webhook is triggered, right? When you entered a typo, what would happen? Will the call end after the (in your example) fifth digit? Can you trigger another webhook to log a failed event?

[arnonym]

Yes, both are not implemented currently.

The error message is the message that is played after entering a wrong PIN. Maybe "No" was a bad example :-). Should've been something like "Wrong code, please try again.".

The early trigger of wrong input is deactivated with the choices_are_pin: true option. In this case you need to enter the number of digits in the longest specified PIN before triggering the error path.

Your assumption about the handling of the correct code is correct.

Currently after entering a wrong code and playing the error_message you would by able to try again. Maybe it makes sense to add more options here.

Also the idea of triggering the webhook for wrong inputs makes sense.

This could be handled like that, and also the error_message option could be removed:

service: hassio.addon_stdin
data_template:
    addon: c7744bff_ha-sip
    input:
        command: dial
        number: sip:**620@fritz.box
        menu:
            message: Please enter your access code
            choices_are_pin: true
            choices:
                '1234':
                    id: owner
                    message: Welcome beautiful.
                '5432':
                    id: maintenance
                    message: Your entrance has been logged.
                'default':
                    id: wrong_code
                    message: Wrong code, please try again
                    post_action: hangup

Very nice discussion we're having here!

[EnerGeh]

Yes, I'm also enjoying the discussion here and looking forward to an adaption. I got your point with the error message, I assumed it is a kind of a switch but it's simply the spoken message in case of an error - thanks for that explanation.

The early trigger of wrong input is deactivated with the choices_are_pin: true option. In this case you need to enter the number of digits in the longest specified PIN before triggering the error path.

Got it, we've switched into another handling mode here, so the early trigger is deactivated and that definitely makes sense here! One hint from my side: Another option could be that you end pin input with '#' or '** key, then you can even handle different digit lengths - but that is optional and I personally don't like defining keys as input endings - it's an annoying additional key press without any security advantage ;-)

Currently after entering a wrong code and playing the error_message you would by able to try again. Maybe it makes sense to add more options here.

From a security perspective, it would be a good option to end the call after a wrong pin input, but making this configurable is even more convenient.

Also the idea of triggering the webhook for wrong inputs makes sense.

Absolutely! And this looks again extremely straight-forward in your example, In my opinion, this is a pretty elegant method to handle pin inputs. I assume, the timeout timer will also handle a "no input" session and end the call after timeout? I don't need an additional webhook on this timeout event, but could be a use case for others (maybe). As far as I understand your code, it would even be possible to read the current pin codes from variables during runtime, so that e.g. a daily/weekly/frequent change of pin codes can be implemented without adjusting the yaml code. Is that right? This could be a WAF-friendly way e.g. to handle one-time-codes like for a friend "step in and take that stuff from the table, you have 120mins to use code 1234". I'm thinking about a dashboard page where you automatically generate this one-time-code and have a slider how long it should be valid.

Please allow me one personal question: According to your configuration (you're using a Fritzbox) and your name: Are you a german native speaker? I'd prefer discussing further in English that is better known by a wider audience, but I'm just interested where you're living :-) Edit: Looked at your Profile and schüttelte den Kopf über meine eigene Verwirrtheit. Dass mir das nicht früher aufgefallen ist! Auf jeden Fall: Cooles Projekt und danke für deine schnellen Antworten!

[arnonym]

In regards of the dynamic creation of the commands to ha-sip I have to say I never did something like that, but I guess you could use some template data for that, Would like to know if you achieve that and add that to the docs.

Timeout is currently not handled, but I would put that on my To-Do list.

Which architecture do you run your home-assistant on? Probably one of aarch64 or amd64? I would like to provide a beta version for this on https://github.com/arnonym/ha-plugins-next and compiling the docker image for all architectures takes a really long time, so I would only compile the version you need for testing.

Aus welcher Gegend Deutschlands kommst du?

[EnerGeh]

Yes, I think template data should be possible in that context, I'll try this out and give feedback on this. I'd be very happy to contribute my 2ct to the docs! In my opinion, a timeout is a must-have for the pin handling, but of course, this is something we can focus on after the beta tests. I'm running a full home assistant os in kvm on a amd64 hardware but hopefully get my home assistant amber in a couple of weeks, so this would be arm64 I think. I'm really looking forward to amber so that I can switch this important part of our daily life to a dedicated hardware. Ich komm aus der Südpfalz. Wenn du mal in der Gegend bist, sagst Bescheid, auch hier gibt es gutes Bier ;-)

[arnonym]

The first beta is now available on. Add https://github.com/arnonym/ha-plugins-next to your add-on repositories and install the -next plugin after.

You need to change the addon bit in your action to 8cd50eef_ha-sip-next like in the example below. Timeout option is already included. The time-out count-down starts when the message starts to play, so add some seconds if you have a long message.

Looking forward to your feedback!

service: hassio.addon_stdin
data_template:
  addon: 8cd50eef_ha-sip-next
  input:
    command: dial
    number: sip:**620@fritz.box
    menu:
      message: Please enter your access code
      choices_are_pin: true
      timeout: 10
      choices:
        "1234":
          id: owner
          message: Welcome beautiful.
          post_action: hangup
        "5432":
          id: maintenance
          message: Your entrance has been logged.
          post_action: hangup
        default:
          id: wrong_code
          message: Wrong code, please try again
          post_action: return

[EnerGeh]

Thanks for that fast implementation. I ported my configuration to the new plugin recently and struggled a bit with the current door bell setup, so I cannot fully confirm that it's working but several staging tests have been successful. But all issues during my testings are related to the door bell's hard- or software - I'll have to dig deeper into that as well.

Some feedback: I really like the possibility to configure the post_action that restarts the whole menu in a loop. I'll definitely have a look into variable choices as well as working with the webhooks but this could need a couple of days from now. I hope this will not annoy you to much as I really appreciate your progress on that.

Some funny stuff I love with tts software in general: It's so cool when you enter your door pin and your door bell welcomes you with "Welcome home, Mr. Bond." ;-)

For the next steps: Should we head over to the HASS forums and post that new way of entering pins to the alarm integration so that more people get aware of that and start beta testing?

[arnonym]

I would rather keep that next repo not so widely used because that might break anytime for my own testing. I also use this one now for my daily door ringing needs, so would merge that, if you don't find any problems. After that I'm happy if you make that more public and drive the star count up here on github :-).

I also hope your wife gets her own PIN and message :-).

[EnerGeh]

I fully understand your point according the next repo. I recently discovered that I completely misunderstood the configuration of my doorbell in that point and currently it seems to be impossible to trigger an action from the doorbell by simply swiping your access card (it has an inbuilt card reader) without entering a PIN on the door station. I'll discuss this with the vendor - they look promising responsive in their forums. I'd prefer using both (PIN and card) over a PIN only setting (2nd-factor-like: something you own & something you know). But of course I did some testings with your PIN implementation in General and could confirm that it's working. Edit: I found one issue: when you enter more digits than defined, the menu will state "unknown option" while it's still reading the message. I will now look into the template options how to read the PINs from a HASS variable.

Btw: Of course Mrs. Bond has her own PIN and message ;-)

[arnonym]

That's a bummer that your plan did not work out. Let's hope the vendor can provide the missing link. May I ask which doorbell we are talking about?

I also added the possibility to answer calls through ha-sip, so I can call home-assistant and after entering the PIN the front-door will be opened (also MFA: you need to have my SIM card, because only known numbers are answered and know the PIN).

For this I revamped the whole docs, as they were organically growing and a bit unstructured lately. If you would like to do me a favor I would be happy if you could read through them and see if everything is clear to you: https://github.com/arnonym/ha-plugins-next

Oh, and the bug: I think I fixed that in the latest version on "next" already. So if you have time you can check that again!

[EnerGeh]

Hi Arne, good news: I opened a ticket with the vendor and got a hint that pushed me to the right direction. Now, I'm able to configure the door station to trigger an event on a simple card swipe without a local PIN input. :smiley: In the next days, I will further integrate that into my HASS instance and finally enable ha-sip for the entry PIN check.

I'm currently using Grandstream "facility access systems" (sic!) and I own both devices, GDS3705 and GDS3710 where the latter features an additional FullHD camera. The main reason why I choose these (I think chinese manufactured) devices was the reasonable price tag compared to the "typical" Siedle or Behnke devices. They feature both a number key pad, a card reader, an ok-ish microphone and speaker combination, a hall sensor as tamper protection (not unimportant as you bring an ethernet cable outside your house) and a pretty solid manufacturing quality. I also didn't want any of these cloud connected door bells like ring, doorbird etc. - I'm not a cloud fan at all.

Answering calls trough ha-sip is a very nice feature, I'll definitely find a use case for that as well :zany_face: Your development speed is extraordinary - I have completely no hacking skills, so I'm very impressed! :+1:

I will definitely check the docs (probably next weekend) and review the bug fix. All I need is a nuance more spare time... I'll keep you posted!

[arnonym]

Nice you got that worked out! Interesting product with an interesting price point you got there. I have also the goal that everything in my house should work without internet connection. Home Assistant works really well with that.

Looking forward to your test results!

[arnonym]

Can you please update to latest beta before you start testing? I had to do some refactoring, and it would be nice, if this is included in the tests also!

[EnerGeh]

I upgraded to beta8 tonight and got the following error:

s6-rc: info: service s6rc-oneshot-runner: starting s6-rc: info: service s6rc-oneshot-runner successfully started s6-rc: info: service fix-attrs: starting s6-rc: info: service fix-attrs successfully started s6-rc: info: service legacy-cont-init: starting s6-rc: info: service legacy-cont-init successfully started s6-rc: info: service legacy-services: starting s6-rc: info: service legacy-services successfully started parse error: Expected string key before ':' at line 1, column 4 [22:12:53] ERROR: Unknown HTTP error occured Traceback (most recent call last): File "/ha-sip/main.py", line 143, in main() File "/ha-sip/main.py", line 100, in main port=int(config.PORT), ValueError: invalid literal for int() with base 10: 'null' s6-rc: info: service legacy-services: stopping s6-rc: info: service legacy-services successfully stopped s6-rc: info: service legacy-cont-init: stopping s6-rc: info: service legacy-cont-init successfully stopped s6-rc: info: service fix-attrs: stopping s6-rc: info: service fix-attrs successfully stopped s6-rc: info: service s6rc-oneshot-runner: stopping s6-rc: info: service s6rc-oneshot-runner successfully stopped

I used the configuration from beta6 without any changes but couldn*t find any issues in my config. Do you have a hint or is it related to your last refactoring of the code?

[arnonym]

I don't get that. Can you check the config in ha again? is there by chance a ":" missing after port?

[arnonym]

This is released as of version 2.0. If you still have problems or need support feel free to re-open this ticket or create another one.

[Dunkelschunkel]

hi @EnerGeh Just out of curiosity - did your idea of changing the pin codes without adjusting the yaml lead to anything in the end?

As far as I understand your code, it would even be possible to read the current pin codes from variables during runtime, so that e.g. a daily/weekly/frequent change of pin codes can be implemented without adjusting the yaml code. Is that right? This could be a WAF-friendly way e.g. to handle one-time-codes like for a friend "step in and take that stuff from the table, you have 120mins to use code 1234". I'm thinking about a dashboard page where you automatically generate this one-time-code and have a slider how long it should be valid.

[EnerGeh]

I'm so devastated that I didn't answer for such a long time. @arnonym I've seen that with the recent updates the PIN input feature evolved massively and is unbelievable useful. Thank you so much for your effort in this! @Dunkelschunkel unfortunately, I didn't find any suitable way to import a variable in runtime. In my opinion it should be possible with a kind of custom code but I'm still learning how to deal with that... In the meanwhile: Sorry, no, I didn't find a solution so far.

[arnonym]

Hey @EnerGeh, don't worry, sometimes life gets in the way. I sometimes get questions about those door stations that call ha-sip, but as I don't have one I can't answer from my own experience. Could you write some paragraphs with example yaml code for the docs for that? I would appreciate that very much!

[EnerGeh]

Could you write some paragraphs with example yaml code for the docs for that? I would appreciate that very much!

It would be a pleasure to do that but my time is still very limited. Give me some weeks to write a couple of lines - it's in my backlog. Feel free to ping me if I didn't answer for let's say 8 weeks or so. Do you mean questions about these Grandstream door stations or sip door stations in General?

[arnonym]

Maybe it makes sense to use the Grandstream door station and its quirks as an example. So how your incoming_sip.yaml config is looking (if there's one), which automations did you create, etc. Looking forward to your contribution!

[EnerGeh]

You're question is still in my backlog (and in my head). Life is hard currently.