OpenTouch Notification Service solution

Transcription

1 OpenTouch Notification Service solution Remote demo and self-training Lab Ed06 Contents 1 Introduction Set up the simulation environment RDP OTNS Your Phone as simulation tool Use the phone to trigger an alarm Use your phone to be notified Your as simulation tool Emulate a DECT phone alarm UA phone set Scenarii about interfaces ASCII PRINTER Interface Objectives ASCII service Setup Correction procedure SNMP Objectives HTTP I/O sender Objectives Smart App Objectives GFP and RTC Objectives DECT base station... 30

2 Objectives Scenarii around lone worker protection and DECT Prerequisites Platform setup What we must know about Questions Exercise Scenario exercise Lone Worker Protection complement How to proceed in real life Other scenarii OTNS redundancy Profile, RTC-GFP trigger Calendar & scheduler Calendar... 38

3 3 Implementation 1 Introduction This document is an introduction to the OTNS remote lab to be used for self-training and demos. One workday will be needed to achieve the main parts, which include the integration of ASCII/SNMP/HTTP I/O/SmartApp. A second work-day will be needed to work through the introduction to DECT. There are useful functional examples at the end of this document to dig into later. The prerequisites for these exercises are to have completed the training, downloaded and reviewed the product documentation available from Business Portal website located in: Software download OTNS. Get your experience now! 2 Set up the simulation environment The remote lab is based on a simulation environment connected to an OTNS and an OXE. The simulation environment is based on a PC with remote desktop access and an Automatic Attendant, in order to simulate DECT calls and generate DECT alarms. All different exercises cover the usual interfaces associated with this field: ASCII printer for fire alarms, SNMP for devices, http I/O for applications, SmartApp for remote notification and DECT for lone worker protection. ESPA protocol is an advanced ASCII protocol that is not explained in this exercise, and, the principle of process are closed to the ASCII printer RDP An will be sent with the login credentials to connect to RDP windows PC, after successfully reserving the remote lab This PC will be allow a connection to the OTNS. Access to an SNMP simulator, an http I/O

4 4 sender and receiver and an ASCII simulator is possible to make the best of a UA IP desktop Soft Phone OTNS Use an internet URL present on the desktop, to connect to OTNS. The account/password is admin/admin Your Phone as simulation tool Use your phone (mobile or fix) as a test tool. The phone will be used to receive notification from OTNS and to simulate a DECT set to generate/trigger alarms. Here is an example of the configuration needed to achieve results Use the phone to trigger an alarm Create an OXE device type Interface telephone to be able to send alarms to the system. This device will be used to simulate alarms from an ALE DECT set, by calling a dedicated number and choosing the voice menu to simulate a of DECT alarm type. To retrieve the device number call and select the choice Test 0.

5 5 Check in the logs files to find the device number And then check the log files Use your phone to be notified Create a second device associated to your phone used for the test. This device will be used to receive notification from OTNS through the PSTN. Modify the Device number with your own public phone number, including the +International_prefix except for FRANCE/ Do NOT include the first 0 for France Update the notification number beginning with 000 country_prefix followed with your number because the system is located in France.

6 Your as simulation tool Configure your own address to receive notifications from OTNS by replacing in the screen shown here. To send to OTNS to trigger an event flow use the destination address: 2.5. Emulate a DECT phone alarm In the next exercise you will have to create alarms from your emulated DECT. To do so, you can call the Automated Attendant at and use the choice 1 to simulate a DECT set behavior. Select the DECT base station 1, 2 or 3, then the simulation to start. Use: 1-man down, 2-Panic, 3-Key 1. That will trigger the associated alarm on behalf the device you created as the pseudo-dect UA phone set Launch the IP Desktop Softphone from the RDP PC. This IP phone is an OXE telephone set on which you will be able to notify alarms in different ways: Full, Simple, Mini and Voice.

7 7 Full mode: is the display for NOE desktop and IP Desktop softphone devices, to have the notification text message and to drive the display. Simple mode is the display mainly for the OXE DECT and OXE SIP sets, to have a call with a notification text message. There is no way to drive its display. Mini is the usage of the mini message of OXE on set (NOE and OXE DECT) to receive notification in the mail box. This is mainly used for information, and, not for alarms that must be processed in real time. Here is an example of a notification block. Note the service, target device. The Message type can be Full, Simple, Mini, Voice, and Loudspeaker. Also note the Display message and the Voice guide file name. Here is the icon used to start the IPDSP. This is a real phone and users should be able to hear the OTNS voice message when a notification associated to a Voice Guide is received. Here is the icon on the IPDSP to access messages. Click on it to empty messages if any exist

8 8

9 9 3 Scenarii about interfaces 3.1. ASCII PRINTER Interface See and review the tutorial about the ASCII interface from the material. The ASCII interface is the basic fire alarm interface, even though some of them use ESPA protocol (supported by ALE OTNS) to communicate with the OTNS. ASCII interface is a RS232 output to a Moxa box, to transform to IP protocol and connect to OTNS Objectives Be able to check the complete integration: the license, start an integration, test integration through log files restart the service or the system. Be able to create an ASCII printer event flow to notify the Real Time Console, in order to run internal test simulation during the event flow of the alarm, and, externally with the ALE simulator ASCII service Setup Correction procedure Verify the license There can be two printers that generates messages to OTNS located here Query the printer configuration

10 10 Enable the integration and note the port number used to communicate with the server Start the service

11 11 Refresh the explorer Check the log files to search for errors. The log files can be downloaded.

12 12 The socket is not available for the service, in this example The first solution will be to re-start the OTNS and check the services after re-start Create a Printer device

13 13 Send a string to the device & retrieve this string in the log files. This is to emulate a message from a Moxa BOX, which is the only way to interconnect to the ASCII system. There is a batch file in the DSP, to start the simulation, but the following command can also be used. c:\program Files (x86)\packetsender>packetsender.exe taw alarm 500 Did you locate the message in the log files? Add an event flow to the test event group, to notify it to the RTC Collect all alarms by filtering on two key words: alarm and 500. Note that the space is a separator. Double click on the red block called Printer To notify all the users connected to the RTC, and, to provide display time stamp, together with the message received from the interface and an additional message. The test account is edemo or admin. It can be seen from the selection that the notification can be only done for some users.

14 14 Include time stamp in the alarm text, to obtain the time of arrival notification. In addition, the auto generated provides the message received including the message location, if defined. Double click on the green block RTC Save the application Open the real-time console in another window

15 15 Launch an internal test from the event flow from the red block Printer. Notes Test the wildcard capacity, determine what a keyword is, retrieve a key word, a sub part of keyword, and a range (1 to 5) by modifying the alarm message. Check the results Run a test from packetsender from the batch file and by typing the line for the alarm 501. c:\program Files (x86)\packetsender>packetsender.exe taw alarm 501

16 16 Note the difference of the information provided comparing to the internal test. Copy the RTC screen and save it to a document on your PC SNMP See or review the SNMP tutorial. SNMP process is useful to monitor devices. To take SIP phones along a highway as an example. These phones run periodic test and send SNMP traps if any issues are detected with the hardware. Issues can be: mic out of service, high speaker out of order and so on. The devices SNMP traps can alert the highway manager on duty and locate the faulty devices on a map. This could be a highway, a train line, electricity or data network equipment, server equipment, cooling machine, etc Objectives In this module we will be able to start an integration, test the integration, be able to create an SNMP receiver event flow and notify the Graphical Floor Plan to be able to test it internally and externally. Use the RDP and the tools available on the desktop Retrieve the SNMP batch file in the RDP desktop Cmd: SnmpTrapGen.exe -r: t:10 -c:"private" -to: vid: vtp:str -val:"mytrap" Check the SNMP configuration and restart the service

17 17 Create the OID to track

18 18 Create the PC Rdp Trap snmp location in the BackOffice Associate it to the device Locate it on the GFP

19 19 Click on and click in the plan to place it, then right click on it to access the menu Select the location created. The size of the icon can be increased.

20 20 Create an event flow to display an alarm on the GFP provided by the SNMP trap Test the event flow The alarm is not attached to a location during an internal test! and check from GFP with Healthcare plan selection Use the snmp command or batch file to test: SnmpTrapGen.exe -r: t:10 -c:"private" - to: vid: vtp:str -val:"mytrap" Check the logs for snmp service Retrieve the alarm on the GFP

21 21 Click on the red icon to get the right floor plan

22 HTTP I/O sender The http I/O interface is the way to interconnect OTNS with the application that is considered as the API of the OTNS. We will integrate it when some protocol is not directly integrated within the OTNS. For example, integration of the OTC PC to provide an alarm from the application. Review the tutorial about the integration from the material Objectives To be be able to test integration through log files, and be able to create an http I/O event flow to notify the GFP with localization based on a wildcard. To be tested both internally and externally. Check the host and the device to receive the message

23 23 Notify the RTC with office1 location linked to the OTC Alarm message.

24 24 Use the RDP and tools provided by the batch file, or use the command to simulate an application sending an alarm to OTNS: c:\users\demootns\appdata\local\apps\curl\bin\curl.exe params: -s Retrieve the alarm in the RTC 3.4. Smart App The smartapp is an application on a smartphone, that can access the OTNS from Wi-Fi or 4G network. It generates an alarm similar to a panic alarm, and receives alarm notification. See the Profile tutorial to understand how to set profiles, to modify the event flow behavior. SmartApp is able to connect a camera in RTSP protocol linked to an alarm or the camera can be directly accessed, if authorized. In addition, the SmartApp can support a SIP Phone connected to OXE Objectives To be able to test the integration through log files, restart the system. Be able to create a SmartApp integration with a user and a SmartApp localized with Maps on RTC and on SmartApp. Test the video both internally and externally. Check the license for smartapp android Start the service for the smartapp Android Create a user that is able to use a smartapp

25 25 Create a smartapp device with the user identification Download the OTNS 6.2 smartapp from Google Play and set up the external OTNS server IP address equals : This is the firewall address forwarded to the OTNS. The port number 5672 is used. Login into the application Create an event flow to cause a Panic SmartApp event to notify the RTC and an event on the SmartApp 20 sec after the RTC.

26 26 Display the localization on the RTC and on the SmartApp. Configure the server connection, and check with network administration that the port 5672 is open, or use the 4G mobile data.

27 27 Check the GPS location by double clinking on the GPS reference. Acknowledge the alarm. To generate an RSTP video stream: Apply the following operating mode to provide a video stream. Launch the VLC batch file that will start the RTSP stream. The video will take a while to be shown, be patient. Create a video URL and assign it to the notification to the SmartApp. The is the public

28 28 address of our OTNS. Generate a SmartApp Panic Alarm from the SmartApp

29 GFP and RTC You already use both of the user interfaces RTC and GFP. Here we go deeper in the feature available Objectives To will be able to setup the options of both RTC and GFP, and be able to create an alarm with file and sound. Test this feature internally and externally. Sound and document already downloaded and the popup URL document Check the presence of a sound *.au and a file *.pdf in the system Modify one of the event flows to associate a sound and a file to a RTC and a GFP event notification. Generate an alarm and from RTC or GFP, localize the sound icon and the file download

30 DECT base station One of the main advantages of the OTNS is integration with the OXE, and especially with the DECT for the lone worker protection and mobility notification service. The DECT integration allows the notification to be geo localized, according to the strongest base station signal. This can be improved with BTLE (Blue Touth Low Energy) detection for the DECT Objectives To be able to create a base station and localize it on GFP Cal and select choice 1/3/1 Retrieve the base station number to be used from the material documentation and create the base station: OpenTouchNotificationService_QuickStartGuide_OXE.pdf Export ale_oxe_api logs, search the day logs: application_logs_2016_12_27_11_31_27_879.zip\diagnostic\logs\home\iqm\dist\iqm-engine\logs DEBUG [ :46:08,408] [ABCFEventListener] ApiEventListner - Notification Call received from user DEBUG [ :46:08,408] [ABCFEventListener] ApiEventListner - From and type NOTIFICATION_CALL DEBUG [ :46:08,408] [ABCFEventListener] ApiEventListner - pari rpn1 017 and signallevel1 3 DEBUG [ :46:08,408] [ABCFEventListener] ApiEventListner - pari rpn2 021 and signallevel2 4 DEBUG [ :46:08,408] [ABCFEventListener] ApiEventListner - pari rpn3 256 and signallevel3 0 DEBUG [ :46:08,409] [ABCFEventListener] ApiEventListner - pari rpn4 256 and signallevel4 0 DEBUG [ :46:08,409] [ABCFEventListener] ApiEventListner - Base stations number 2 after filtering DEBUG [ :46:08,409] [ABCFEventListener] SCPLocation - Stations 2 received DEBUG [ :46:08,409] [ABCFEventListener] AlcatelPositionLocator - Filtered stations 2 DEBUG [ :46:08,409] [ABCFEventListener] AlcatelPositionLocator - Strongest station Note that the daily logs are located in: application_logs_2016_12_27_11_31_27_879.zip\diagnostic\logs\home\iqm\logs

31 31 Retrieve the message and the base station ID and create it Create the location Create the device together with its location Locate it in the maps

32 32 Create a script to display the man down alarm of a DECT in the GFP 4 Scenarii around lone worker protection and DECT Context: Detect a major anomaly that was produced by an employee using panic mode. There should be no need to remind who to call Scenario: long press on alarm button, RTC displays the alarm, GFP localizes the best base station, a telephone set is notified. The call is escalated to a SmartApp user, if the call is not acknowledged Objectives: Describe the PTI function of the 8262 Describe the interface of notification RTC, GFP, Sets, SmartApp Introduce the eventflow Retrieve the PTI function from the Red OXE block Retrieve the notification possibility Describe the escalation process 4.1. Prerequisites Training ONTSWPS001 on knowledge hub for the BP Follow the tutorials from the community Platform setup Open a Firefox Mozilla and launch from your PC Account: admin Password: admin One screen open to RTC: One screen open to GFP: What we must know about 8262 Identify the 8262

33 33 Describe the localization of the panic button (or emergency call), the pull cord, man down no movement and shock. See more in the documentation here: Questions. What happens when a man down is detected by the phone?... What type of ringing will be produced... Can I stop an alarm if started unexpectedly?... Can I have a grace period to avoid startind an alarm in case of an unexpected man dow alarm? What happens if the set is out of coverage?... How is the user adviced? Exercise Scenario: Emulate a panic button situation with a long press on the alarm button. RTC displays the alarm. GFP locates the best base station. A set is notified. The call is escalated to a SmartApp user, if not acknowledged Describe the text display method when alarm is notified. Will it be Full display or Mini message? Describe the loudspeaker mode Build your scenario

34 34 Call the Automated Attendant choice 1/1/2 Open RTC and activate the alarm through the Automated Attendant phone number Note the difference between the notification from OXE block and from the RTC block On the IPDSP note the management of the text on the phone set. Force the loudspeaker available for the UA set and not for your remote Test Set. Notes Full is dedicated to UA set, simple is dedicated to DECT, but can be used on UA.

35 35 The call back number will be used when Take Call is pressed on the IP DSP, when the call is presented. Use 000Country_code_Your_Number to test The Full mode apply only on UA set not on DECT that use Simple Test the Simple mode and the Mini mode Scenario exercise To be able to describe: RTC display the alarm Color of displays are manageable to provide a better understanding GFP localize the best DECT base station Color of display are manageable to provide a better understanding The UA XXXX is notified by call and text Type of Test message, type of call, priority (MLPP, DND and FWD) Escalation management according to the connected block Accepted, answered

36 36 Describe the Retrieve the PTI function in the Red OXE block Retrieve the notification possibility Describe the escalation process In addition, play a sound on the RTC and provide a document to download at the RTC.

37 37 5 Lone Worker Protection complement 5.1. How to proceed in real life Describe the function at the 8262 level Enter in the alarm menu Select Access to Alarm settings menu (password). Underline the restriction access by password. Describe the Alarm trigger and activate the ManDown function Select Alarm to server Select Settings and describe the angle and the location signal Describe the set behavior when out of the coverage zone. Set the phone set horizontal and re-describe the behavior Don t ack the alarm Remove the localization ringing by acceding the alarm ack icon in the menu

38 38 6 Other scenarii 6.1. OTNS redundancy Exercise with documentation only Describe the OTNS redundancy Describe the update mechanism thru the Linux cluster and keep alive for activity detection (see documentation) Retrieve the port used by the cluster 6.2. Profile, RTC-GFP trigger Calendar & scheduler Calendar Create a script based on DECT Key1 trigger that have a different behavior during the open hour Notify the ua set the rest of the week. Notifiy by Create the device Daily Test scripts Scenario: programmed automatic procedure to verify the emergency process Call emergency DECT All must accept If one of them does not escalation to IP Desktop Soft Phone Create the group to test

39 39 Schedule the test

40 40 RTC-GFP Create a script that is activated by RTC or GFP Notification to Simple event flow activated by RTC trigger Assign the RTC trigger to the event flow

41 41 Retrieve the RTC trigger in the RTC Send and receive the , localize the Subject and the body of the message Profile Create the previous script to use a profile Edit the profile Create the profile name and press to validate the switch name Add switch and validate Add a second switch and validate

42 42 And select a switch Then connect to block Re-select the profile block and select the second switch Create the rest of the event flow Save the event flow How to retrieve the Profile from RTC

43 43 Add row

44 44 User can manage the profile User set it from RTC Report Generate a report and identify the acknowledgement from one of your scenarios

45 45 Note that it is only when an escalation is processed, that the accepted/refused answer will be displayed