I have no experience with the HDL Nordic rpi server, so you should check with HDL if you can use RPi hats on their product.

I have iRidium and Zway server running on a single RPi with the RazBerry HAT. They communicate over HTTP API, so you could also run them on separate RPi's.

https://z-wave.me/products/razberry/

We prefer to stay away from modem type boxes and stick with DIN-rail modules to keep the install neat. There are multiple options for RPi, but I've never seen DIN-rail enclosures for other Zwave controllers.

Also an option is to a RPi with RazBerry addon. iRidium can also run on the same RPi or separate. I choose this option so I could stick with DIN-rail modules and put a RPi in a DIN case.

Same here. I'm sure we don't know all the details, but it doesn't seem too complicated to create functionality in which virtual channels can be set from the panel in combination with using virtual channels for setting these kind of values/settings?

In my opinion this basic usability function would be more urgent then BYOD functions which is more a sales gadget.

I understand from a similar topic the ETA on this is spring 2018

Thanks. No rush, but I think this might get more in demand in the coming period. Especially if the wall-panels become more affordable this way. So we'll see if the voting will help.

Hi, I disagree :)

In peer-to-peer communication the destination of the call needs a fixed open port, not a random port. How would the doorintercom otherwise know on which destination port he can reach the clients if they are random? 

The sender from which the call originates is of course allowed to use a random source port as most protocol provide a mean of letting the other side know on which port they would like to receive their reply.

This is exactly why SIP servers comply to the ISO standard and listen on a fixed port (as do all major transport services such as email, DNS, etc.). If the solution is not in the fixed port, implementing a server to be the intermediary would not have been the (temporary) other solution.

To be able to set a fixed port on which iRidium listens for an incoming SIP call is the solution. Provided there are no other troubles in the used SIP libraries which could prevent otherwise. The mechanism in which the call is setup in a peer-to-peer setup is the same as if it would be routed through a SIP proxy or PBX. The only thing that might be a problem is that the SIP libraries used in iRidium might need an extra configuration to allowed calls from unregistered sources. As registration is not used in a peer-to-peer setup. 

I would like to suggest to reopen the voting for this feature as it is not complete. Yes there is some form of scheduling available, but the FR is more then what is implemented right now. It would become much more clear what the urgency should be if we can vote again. Also I think by putting this FR to status complete there will be no more focus to complete the rest of the needed code.

Ekatarina said it will be implemented step by step. I would also like to suggest the next step is that the settings for scheduling are (optionally) read from project tokens. This way we at least can build our own interfaces to fill the project tokens. This single step would make the whole solution usable for our customers much faster and also putting the FR to completed much more fair.

Thanks!

I just want to put in an extra thumbs up to get the setting available for direct SIP calls, a.k.a where iRidium listens on a fixed port such as 5060 as 99% of the SIP clients can do. Especially because the common use for SIP in iRidium will be for door intercom. In these situations (in home installs) we mostly do not have a separate SIP server available. Even, if I'm at a client (home install) I do not want to introduce a new single point of failure and install a SIP server just to get a working doorintercom-client connection. It is just another box that can fail and just another piece of software which has to be maintained. 

I haven't had time to test this yet. But Aleksandrs reply seems feasible. Did you give it a try?

Thanks!

Somehow the search feature only brought up #Popen which does nothing on the client side.