Drivers MPP Port Devices



Sun StorageTek RDAC Multipath Failover Driver Installation Guide for Linux OS

Download the latest drivers, software, firmware, and diagnostics for your HP products from the official HP Support website. However, if you want to use a 3rd-party bus controller, or develop your own to use with your Windows pen device, you can do that. If you want your pen device to connect via an alternate bus, then a 3rd-party HID mini-port driver might be required, and would be allowed according to the Windows 10 HLK requirements.

Sun StorageTek RDAC Multipath Failover Driver for Linux OS

The Sun StorageTek Redundant Dual Active Controller (RDAC) failover drivers support the following Linux OS distributions for the 2.6 kernel:

  • SuSE SLES 10 SP1 and SLES 9 (x86, x86_64, IA64)
  • SuSE Linux Enterprise Server 10 SP1 and 9 for IBM eServer pSeries
  • Architectures (ppc64)
  • Red Hat RHEL 5 (x86, x86_64, IA64)
  • Red Hat Advanced Server 4 (x86, x86_64, IA64)

Note - The failover driver for Linux OS RDAC does not support any Linux OS 2.4 kernels such as SuSE SLES 8 OS on Intel architecture or AMD architecture, Red Hat 3 Linux OS on Intel or AMD architecture, and Linux OS SLES8 and Red Hat 3 on POWER (LoP) servers.

About RDAC Multipath Drivers

Redundant Dual Active Controller (RDAC) is the failover driver for the Sun Storage 6180 array, StorageTek 6000 array series (includes Sun Storage 6580 and 6780 arrays) and Sun StorageTek 2500 array series. The RDAC failover driver includes these features:

  • On-the-fly path validation.
  • Cluster support.
  • Automatic detection of path failure. The RDAC failover driver automatically routes I/O to another path in the same controller or to an alternate controller, in case all paths to a particular controller fail.
  • Improved I/O retries. The RDAC driver handles vendor-specific SCSI error codes from the array controllers.
  • Automatic rebalancing. When the failed controller obtains optimal status, storage array rebalance is performed automatically without user intervention.

Note - The RDAC driver cannot co-exist with an HBA-level failover driver such as the Emulex, QLogic, or LSI Logic HBA failover drivers.

Prerequisites

Before you install the RDAC driver, be sure the following requirements are met:

1. The HBAs connected to the host on which you are installing the RDAC driver are supported. The driver supports QLogic, LSI, and Emulex HBAs. (For supported HBA model numbers, see the README file included in the RDAC driver package, as described in Downloading the RDAC Driver.)

2. The compiler and kernel source for the appropriate OS are installed.

3. The HBAs connected to a single storage array are the same model. Use your HBA utilities, such as HBAanywhere (Emulex) or scli (QLogic) to ensure that your storage area network (SAN) is configured properly for this requirement.

4. The base HBA driver is installed and built. The following base and host drivers are supported:


HBA

Base Driver Name

Host Driver Name

Notes

QLogic

qla2xxx

qla2300

LSI

mptbase

mptscsi or mptscsih

mpt driver version earlier than 3.02.xx

mptspi, mptsas, and mptfc

3.02.xx or later for SCSI parallel interface transport, SAS transport, and FC transport respectively.

Emulex or IBM Emulex

lpfcdd or lpfc

lpfc


5. To verify the driver is installed, use the following command:

The following sample output shows QLogic drivers (in bold text):

Downloading the RDAC Driver

The Linux OS RDAC driver is available for the following storage products:

  • Sun Storage 6180 array
  • Sun Storage 6580 and 6780 arrays
  • Sun StorageTek 6000 array series
  • Sun StorageTek 2500 array series

The Linux OS RDAC driver is compatible with array controller firmware version 06.19.25.16 (minimum). Array firmware is bundled with Sun StorageTek Common Array Manager (CAM) and is also available at the Sun Download Center (see the URL in Step 1 of the following procedure).

RDAC drivers are available from the Sun Download Center.


Caution - MPIO and RDAC cannot coexist on the same Linux host server.

1. To download the RDAC driver, go to:

http://www.sun.com/download/index.jsp?tab=2#S

2. Select the package for the Linux OS platform.


Linux Kernel

OS

Driver

Linux 2.6

Red Hat 4 SuSE 9/SuSE 10

rdac-LINUX-09.xx.xB02.xxxx

Linux 2.6.16.16

Red Hat 5 SuSE 10 SP1 (and above)

rdac-LINUX-09.xx.xC02.xxxx

Linux 2.6.18

RHEL5 (and above)

rdac-LINUX-09.xx.xC02.xxxx


Note - For updated driver information, refer to the release notes for your array.

3. Place the download in a non-volatile location on the system to be installed.

4. Load the standard HBA non-failover driver.


Note - Emulex and Qlogic failover drivers are not compatible with the RDAC driver.

5. On the SuSE operating system, check the base HBA drivers are included in INITRD_MODULES in /etc/sysconfig/kernel for one of the following HBAs:


TABLE 1 HBA Driver Names

HBA

Base Driver Name

Host Driver Name

Notes

QLogic

qla2xxx

qla2300

LSI

mptbase

mptscsi or mptscsih

INITRD_MODULES include mptbase and mptscsi (or mptscsih) for pre-3.02.xx version of the LSI mpt driver.

mptspi, mptsas, and mptfc

The INITRD_MODULES includes mptbase, mptscsi, mptspi, mptsas, and mptfc for 3.02.xx or later version of the LSI mpt driver.

Emulex or IBM Emulex

lpfcdd or lpfc

lpfc

INITRD_MODULES include lpfcdd or lpfc


6. Make sure the kernel source tree is installed for the kernel version to be built against.

Installing the RDAC Driver

The following procedure describes how to install the RDAC driver for Red Hat RHEL 5, Red Hat Advanced Server 4, and Red Hat SuSE.

  • Red Hat RHEL 5 package: rdac-LINUX-09.03.0B05.0042-source.tar.gz
  • Red Hat Advanced Server 4 package: rdac-LINUX-09.03.0C02.0042-source.tar.gz

1. Unpack the source code using the tar command:

where xx.xx.xxxx.xxxx is the RDAC version you downloaded.

The files are copied to the linuxrdac-xx.xx.xx.xx directory.

2. Change to the directory containing the unpacked files. For example,

3. Remove any earlier version drivers that are in this directory by running the makeclean command:



4. Compile all driver modules and utilities by running the make command:



5. Uninstall any existing RDAC drivers using the makeuninstall command:

6. Install the new RDAC driver using the makeinstall command. This command:

  • Copies the driver modules to the kernel module tree.
  • Builds the new RAMdisk image (mpp-‘uname -r‘.img) which includes the RDAC driver modules and all driver modules that are needed at boot time.

7. Type yes when you are prompted to continue:



8. Follow the on-screen instructions to modify the grub.conf file. Change the module and initrd names as follows:


Original Name

Revised Name

module /initrd-2.6.18-8.el5xen.img

module /mpp-2.6.18-8.el5xen.img

initrd /initrd-2.6.18-8.el5.img

initrd /mpp-2.6.18-8.el5xen.img


The content of the grub.conf file looks similar to the following. (The revised module and initrd names are shown in bold text.)

9. Reboot the Linux server.

10. After the server is rebooted, log in and verify the driver stack is properly loaded using the lsmod command. The driver stack for Red Hat and SuSE platforms are as follows:

  • Red Hat platforms--scsi_mod, sd_mod, sg, mppUpper, mppVhba, and base level HBA drivers (for example, qla2xxx, qla2300) are loaded.
  • SuSE platforms--sg, mppUpper, mppVhba, and base level HBA drivers (for example, qla2xxx, qla2300) are loaded.


11. Verify the content of the modprobe.conf.mppappend file:



12. Verify the RDAC driver discovered the available physical LUNs and created virtual LUNs by typing the following command:

13. Verify all drivers are running.



14. Verify RDAC is configured with the MPP drivers.

15. Verify the disk devices are mapped from the array to the host, as follows:

  • Check the array mappings in Common Array Manager, to ensure that you have mapped a volume on the array to the Linux host.
  • Use the /usr/sbin/mppUtil-a<array_name_in_CAM> command to get a report on how many devices can be seen by the MPP driver (see Multipath Failover Driver Utilities).
  • View the /proc/scsi/mpp file for array devices.
  • View /proc/scsi/<base_hba_driver_name>/[0-9|a-z], for information about what devices can be seen.

See TABLE 1 for a list of HBA base driver names. The files in this directory are labeled 0 through 9 or A through Z. Each file represents a port on the HBA, which includes World Wide Names of storage devices and LUNs reported.

Multipath Failover Driver Utilities

The MPP RDAC driver installation creates three utilities for your use:

  • mppUtil
  • lsvdev
  • mppSupport

mppUtil Utility

The mppUtil utility is a general purpose command-line driven utility that works only with MPP-based RDAC solutions. The utility instructs RDAC to perform various maintenance tasks, but you can also use the utility to troubleshoot failover problems.

To use the mppUtil utility, type this command and press enter.

mppUtil [-a target_name] [-c wwn_file_name] [-d debug_level] [-e error_level] [-g virtual_target_id] [-I host_num] [-o feature_action_name
[=
value][, SaveSettings]][-s 'failback' | 'avt' | 'busscan' | 'forcerebalance'] [-S] [-U][-V]


Note - The quotation marks must surround the parameters.

The mppUtil utility is a cross-platform tool. Some parameters might not have a meaning in a particular operating system environment. A description of each parameter follows.


TABLE 2 mppUtil Parameters

Parameter

Description

-a target_name

Shows the RDAC driver’s internal information for the specified virtual target_name (storage array name). If a target_name value is not included, the -a parameter shows information about all the storage arrays that are currently detected by this host.

-c wwn_File_Name

Clears the WWN file entries. This file is located at /var/mpp with the extension .wwn.

-d debug_level

ets the current debug reporting level. This option only works if the RDAC driver has been compiled with debugging enabled. Debug reporting is comprised of two segments. The first segment refers to a specific area of functionality, and the second segment refers to the level of reporting within that area. The debug_level is one of these hexadecimal numbers:

  • 0x20000000--Shows messages from the RDAC driver’s init() routine.
  • 0x10000000--Shows messages from the RDAC driver’s attach() routine.
  • 0x08000000--Shows messages from the RDAC driver’s ioctl() routine.
  • 0x04000000--Shows messages from the RDAC driver’s open() routine.
  • 0x02000000--Shows messages from the RDAC driver’s read() routine.
  • 0x01000000--Shows messages related to HBA commands.
  • 0x00800000--Shows messages related to aborted commands.
  • 0x00400000--Shows messages related to panic dumps.
  • 0x00200000--Shows messages related to synchronous I/O activity.
  • 0x00000001--Debug level 1.
  • 0x00000002--Debug level 2.
  • 0x00000004--Debug level 3.
  • 0x00000008--Debug level 4.

These options can be combined with the logical or operator to provide multiple areas and levels of reporting as needed.

-e error_level

Sets the current error reporting level to error_level, which can have one of these values:

  • 0--Show all errors.
  • 1--Show path failover, controller failover, retryable, fatal, and recovered errors.
  • 2--Show path failover, controller failover, retryable, and fatal errors.
  • 3--Show path failover, controller failover, and fatal errors. This is the default setting.
  • 4--Show controller failover and fatal errors.
  • 5--Show fatal errors.

-g virtual_target_id

Display the RDAC driver’s internal information for the specified virtual_target_id.

-I host_num

Prints the maximum number of targets that can be handled by that host. Here, host refers to the HBA drivers on the system and includes the RDAC driver. The host number of the HBA driver is given as an argument. The host numbers assigned by the Linux middle layer start from 0. If there are two ports on the HBA card, host numbers 0 and 1 would be taken up by the low-level HBA driver, and the RDAC driver would be at host number 2. Use /proc/scsi to determine the host number.

-o feature_action_name[=value][, SaveSettings]

Troubleshoots a feature or changes a configuration setting. Without the SaveSettings keyword, the changes only affect the inmemory state of the variable. The SaveSettings keyword changes both the in-memory state and the persistent state. You must run mppUpdate to reflect these changes in inird image before rebooting the server. Some example commands are:

  • mppUtil -o--Displays all the available feature action names.
  • mppUtil -o ErrorLevel=0x2--Sets the ErrorLevel parameter to 0x2 (affects only the in-memory state).

-s ['failback' | 'avt' | 'busscan' | 'forcerebalance']

Manually initiates one of the RDAC driver’s scan tasks. A failback scan will cause the RDAC driver to reattempt communications with any failed controllers. An avt scan causes the RDAC driver to check whether AVT has been enabled or disabled for an entire storage array. A busscan scan causes the RDAC driver to go through its unconfigured devices list to see if any of them have become configured. A forcerebalance scan will cause the RDAC driver to move storage array volumes to its preferred controller and ignore the value of the DisableLunRebalance configuration parameter of the RDAC driver.

-S

Reports the Up or Down state of the controllers and paths for each LUN in real time.

-U

Refreshes the Universal Transport Mechanism (UTM) LUN information in MPP driver internal data structure for all the storage arrays that have already been discovered.

-V

Prints the version of the RDAC driver currently running on the system.


lsdev Utility

The lsdev utility provides a map of your array LUNs to their Linux block devices. To use the lsdev utility, type this command and press enter.

# /opt/mpp/lsdev

For example:

/usr/sbin # /opt/mpp/lsvdev

mppSupport Utility

The mppSupport utility provides information about your system, array connection, and configuration for Sun Services to assist you with any problems you might have.

To use the mppSupport utility, type this command and press enter.

# /opt/mppSupport

The collected support data is saved in the file:

/tmp/mppSupportdata_myhost_<RDACversion>_<dateandtime>.tar.gz

Linux RDAC Configuration Settings

The RDAC driver contains configuration settings that can modify the behavior of the driver. Any changes to the settings take effect on the next reboot of the host. The default values listed here are the platform-independent settings. Many of these values are overridden by the failover installer for Linux. For Linux, the configuration settings are located in the /etc/mpp.conf file.

After you change a configuration value, you must run the mppUpdate utility and reboot your Linux server for the change to take effect.


Drivers mpp port devices gigabit
Caution - You might lose access to the storage array if you change these settings from their configured values.

TABLE 3 RDAC Configuration Settings for the Linux OS

Setting

OS Default Value

Description

MaxPathsPerController

4

The maximum number of paths (logical endpoints) supported per controller. The total number of paths to the storage array is the MaxPathsPerControllervalue multiplied by the number of controllers.

ScanInterval

60

The interval, in seconds, during which the failover driver will check for these conditions:

  • A change in preferred ownership for a LUN
  • Attempt to rebalance LUNs to their preferred paths
  • A change in AVT enabled/disabled status

ErrorLevel

3

Determines which errors to log. The valid range is from 0 to 4.

  • 0--Display all errors
  • 1--Display path failover errors, controller failover errors, retry errors, fatal errors, and recovered errors
  • 2--Display path failover errors, controller failover errors, retry errors, and fatal errors
  • 3--Display path failover errors, controller failover errors, and fatal errors (this is the default setting)
  • 4--Display controller failover errors, and fatal errors

SelectionTimeoutRetry
Count

0

The number of times a selection timeout is retried for an I/O request before the path fails. If another path to the same controller exists, the I/O is retried. If no other path exists, a failover takes place. If no valid paths exist to the alternate controller, the I/O is failed.

CommandTimeoutRetryCount

1

The number of times a command timeout is retried for an I/O request before the path fails. If another path to the same controller exists, the I/O is retried. If another path does not exist, a failover takes place. If no valid paths exist to the alternate controller, the I/O is failed.

UaRetryCount

10

The number of times a Unit Attention status from a LUN is retried. This parameter does not apply to UA conditions due to Quiescence In Progress.

SynchTimeout

120

The timeout, in seconds, for synchronous I/O requests generated internally by the failover driver. Examples of internal requests include those related to rebalancing, path validation, and issuing of failover commands.

DisableLunRebalance

0

Provides control over the LUN failback behavior of rebalancing LUNs to their preferred paths. The following values are possible:

  • 0--LUN rebalance is enabled for both AVT and non-AVT modes.
  • 1--LUN rebalance is disabled for AVT and enabled for non-AVT mode.
  • 2--LUN rebalance is enabled for AVT and disabled for non-AVT mode.
  • 3--LUN rebalance is disabled for both AVT and non-AVT modes.

S2ToS3Key

Unique key

Value of the SCSI-3 reservation key generated during failover driver installation.


Wait Time Settings

When the failover driver receives an I/O request for the first time, the failover driver logs timestamp information for the request. If a request returns an error and the failover driver decides to retry the request, the current time is compared with the original timestamp information. Depending on the error and the amount of time that has elapsed, the request is retried to the current owning controller for the LUN or a failover is performed and the request sent to the alternate controller. This process is known as a 'Wait Time.'


Caution - Possible loss of data access--If you change these settings from their configured values, you might lose access to the storage array.

The configuration settings can be found in the /etc/mpp.conf file.


TABLE 4 Wait Time Settings

Configuration Name

Default Value

Description

NotReadyWaitTime

300

The time, in seconds, a Not Ready condition (SK 0x06, ASC/ASCQ 0x04/0x01) is allowed before failover is performed.

BusyWaitTime

300

The time, in seconds, a Busy condition is allowed for a failover is performed.

QuiescenceWaitTime

300

The time, in seconds, a Quiescence condition (SK 0x06, ASC/ASCQ 0x8b/0x02) is allowed before a failover is performed.

ControllerIoWaitTime

120

Provides an upper-bound limit, in seconds, an I/O is retried on a controller regardless of retry status before a failover is performed. If the limit is exceeded on the alternate controller the I/O is again attempted on the original controller. This process continues until the ArrayIoWaitTime limit is reached.

ArrayIoWaitTime

240

Provides an upper bound limit, in seconds, an I/O is retried to the storage array regardless of which controller the request is attempted to. Once this limit is exceeded, the I/O is returned with a failure status.


Port

Updating the initrd Image

1. After you change a configuration value, run the mppUpdate utility and reboot the Linux server for the change to take effect. An MPP initrd image is created, as shown in the following example:

2. Reboot the host server:

Troubleshooting Linux RDAC Drivers

How do I get logs from RDAC in the Linux OS?

Use the mppSupport command to obtain several logs related to RDAC. The mppSupport command is found in the /opt/mpp/mppSupport directory. The command creates a file named mppSupportdata_hostname_RDAC version_datetime.tar.gz in the /tmp directory.

How does persistent naming work?

The Linux OS SCSI device names can change when the host system restarts. Use a utility, such as devlabel, to create user-defined device names that will map devices based on a unique identifier. The udev method is the preferred method for SLES10 and RHEL 5.

What must I do after applying a kernel update?

After you apply the kernel update and start the new kernel, perform these steps to build the RDAC Initial Ram Disk image (initrd image) for the new kernel:

1. Change the directory to the Linux RDAC source code directory.

2. Type the following command, and press Enter.

make uninstall

3. Reinstall RDAC.

What is the Initial Ram Disk Image (initrd image), and how do I create a new initrd image?

The initrd image is automatically created when the driver is installed by using the make install command. The boot loader configuration file must have an entry for this newly created image.

The initrd image is located in the boot partition. The file is named mpp-uname -r.img.

For a driver update, if the system already has a previous entry for RDAC, the system administrator must modify the existing RDAC entry in the boot loader configuration file. In most of the cases, no change is required if the kernel version is the same.

To create a new initrd image, type the following command and press Enter.

# mppUpdate

The old image file is overwritten with the new image file.

If third-party drivers are needed to be added to the initrd image, change the /etc/sysconfig/kernel file (SuSE) with the third-party driver entries. Run the mppUpdate command again to create a new initrd image.

How can I see if volumes have been added?

Run hot_add -s or hot_add to add the newly mapped volumes.

How do I remove unmapped or disconnected devices from the existing host?

Run hot_add -d to remove all unmapped or disconnected devices.

What if I remap a LUN from the storage array?

Run hot_add -u to update the host with the changed LUN mapping.

What if I change the size of the LUN on the storage array?

Run hot_add -c to change the size of the LUN on the host.

How do I make sure that RDAC finds the available storage arrays?

To make sure that the RDAC driver has found the available storage arrays and created virtual storage arrays for them, type the following commands, and press Enter after each command.

# ls -lR /proc/mpp

# mppUtil -a

# /opt/mpp/lsvdev

To show all attached and discovered volumes, type the following command and press Enter.

# cat /proc/scsi/scsi

What must I do if I receive this message?


Drivers Mpp Port Devices Replicator

Caution - Changing the storage array name can cause host applications to lose access to the storage array if the host is running certain path failover drivers. If any of your hosts are running path failover drivers, please update the storage array name in your path failover driver’s configuration file before rebooting the host machine to insure uninterrupted access to the storage array. Refer to your path failover driver documentation for more details.

The path failover drivers that cause this warning are the RDAC drivers on Linux. The storage array user label is used for storage system-to-virtual target ID binding in the RDAC driver. For the Linux OS, change the following file to add the storage array user label and its virtual target ID.

Determining if a Path Failed

With the failover driver, two cases determine if a path has failed:

  • A path to a controller has failed, but the driver has other paths to the same controller that it can use. This situation causes a degraded condition and must be corrected before the controller can switch to an alternate path.

An entry is made in the OS system log that shows that the failover driver has detected a path failure. CAM does not generate an alarm because no internal problems exist for the array.

  • All of the paths to a controller have failed, or the controller itself has failed, and the other controller is now used to service the I/O.

CAM generates the “Volume Not on Preferred Path' alarm for all volumes affected by this scenario. If the array administrator has configured notifications in CAM, the administrator will receive email from CAM or a configured SNMP server. You also have the option of opening a service request using the Auto Service Request (ASR) feature of CAM. The resultant message and alarm will provide information about the fault, along with possible recovery instructions.

Error Levels

The failover driver has five error levels for messages that are logged to the Linux OS error log:

  • Fatal errors
  • Controller failover events
  • Path failover events
  • Retry errors
  • Recovered errors

Fatal Errors

TABLE 5 lists the possible Linux OS fatal driver errors.


TABLE 5 Fatal Failover Driver Errors for the Linux OS

Busy wait time exceeded

Busy wait time exceeded on failover command

Close failed on virtual bus node Error trying to insert a new volume path

Discovered device is not a storage array

Duplicate storage array name found

Error trying to allocate data structures

Error trying to create virtual target

Error trying to determine controller slot

Error trying to determine state of volume

Fatal Error Message

Busy wait time exceeded

Busy wait time exceeded on failover command

Close failed on virtual bus node

Command aborted

Command timeout retry count exceeded

Controller unreachable without failback to current (which is disabled)

Discovered device is not a storage array

Duplicate storage array name found

Error trying to allocate data structures

Error trying to create virtual target

Error trying to determine AVT state of volume

Error trying to determine controller slot

Error trying to determine maximum number of volumes supported by storage array

Error trying to determine storage array name

Error trying to get World Wide Identifier (WWID) of volume

Error trying to insert a new controller path

Error trying to insert a new volume

Error trying to insert a new volume path

Error trying to match discovered controller to existing controller

Failover command failed

Failover failed, no path to volume

Failover failed, unable to allocate memory

Hardware error

Incorrect close type for virtual bus node

Incorrect open type for virtual bus node

Inquiry wait time exceeded

Maximum number of storage arrays exceeded

Maximum paths per controller exceeded

No paths available to start I/O

No paths available to start I/O, failing over

Not Ready wait time exceeded

Open failed on virtual bus node

Quiescence wait time exceeded

Received the Illegal Command error from the storage array

Request sense failure

Selection timeout retry count exceeded

Sense key hardware error received

Storage array found to be in state of Not Ready and Not Becoming Ready

Unit Attention retry count exceeded

Unrecognizable OS status

Unrecognized SCSI status

Unrecognizable sense key received

Volume number exceeds the maximum configured volume number

World Wide Identifier (WWID) for discovered volume does not match that of same volume found on another path


Controller and Path Failover Events

The following items are examples of failover driver controller events and path failover events:

  • Change of AVT setting detected
  • Failover command issued
  • AVT failover invoked
  • Path failure detected

Sun StorageTek RDAC Multipath Failover Driver Installation Guide for Linux OS820-4738-13

Copyright © 2009 Sun Microsystems, Inc. All rights reserved.

Non-WeMo device extension app for Automation Manager.

MppDevices is an adapter (proxy) that would run on your WemoServer device, adapting devices other than WeMos to work with WemoManager. It can also be used on your phone if you don't use the WemoServer.

Available on play for a small charge to avoid non-AutomationManager customers from trying it and leaving a bad review when it doesn't work for them, and to help fund new device integration.

The downloadable version on this page can be used to test with Web, Tasker, and Automagic integration before purchasing a license for the maintained version.

Security Advice!!! There are many new and inexpensive IoT automation devices available. Note that these devices only connect to a 'cloud' server to give you easy setup and remote access.

Do you know where these cloud servers are located or who can access them? Neither do I...

But you can use MppDevices to control them rather than the cloud enabled apps, and you can automation them and provide remote access using YOUR OWN server using AutomationManager. Then for complete security you can disable remote access and lock them out with your router firewall.

Currently supported device types are:

  • Orvibo Smart Switches
  • When using the Orvibo devices they must be on the same network segment as MppDevices or you will need to route multicast 255.255.255.255 between segments.
  • TP-Link switches and bulbs are now supported natively in AutomationManager/WemoHome.
  • Usr Iot/Lonhand devices available on ebay for about 1/2 the cost of a Wemo socket.They are available for multiple country power standards including Europe. I wouldn't want to access them through a cloud based in Asia, but you can deny the devices access to the internet and control them using WemoManager and WemoServer.
  • TinyOS based Lazybones relay switches from TinySine. Don't bother. There are cheaper and easier to use devices available.
  • Custom devices built using Tasker or Automagic
    • Intercept MppDevices standard android intents and implement the interface in Tasker. Use the 'Copy Intents' menu for the device to copy/paste the MppDevice intents to your Tasker/Automagic implementation.
    • Extras as needed: state (boolean), value (float), udn (string), name (string), time (int)
  • Custom devices built using a web (REST-like) interface
    • NOTE: you can now use the MppDevices REST interface for native AutomationManager support rather than using this interface through the MppDevices app.
    • Customize the HTTP calls made by MppDevices to your mini-web server running your device. Details are provided in app. Specify a GET url for MppServer to fetch the current state or value (for analog devices) and a PUT url (for switch state changes). On the GET return a JSON body with state or a float value (for analog sensors).
    • Optionally report state changes back to the MppDevices web server with a PUT to ..:8898/report/udnString?state=xxxx or ?value=fffff
    • with either
    • state is true or false
    • value is a float
  • DTMF devices - plays a tone. Currently handy for testing but will be more useful in the future.
  • Phone information, for use with battery minders
    • BatteryLevel (analog sensor, value - battery charge level)
    • BatteryHealth (sensor, 'on' if battery is healthy)
    • ChargingWireless, ChargingAC, ChargingUSB (sensor)
    • Charged (sensor, on when battery fully charged)
  • Notification - display a notification to your phone
  • Custom (low end) android phones driving relays. Some assembly required. The phones adapt them to wifi/AutomationManager via MppDevices for a very low cost

The 'Discoverable' checkbox controls whether each device will be visible to your WemoManager/WemoServer.

Drivers Mpp Port Devices Download

AutomationServer

Typically you will install MppDevices on the same android device you use for running your AutomationServer. You need at least one device defined before MppDevices will respond. Use a DTMF device (on/off sounds a tone on the phone/tablet) as it's handy for testing.

When installed on the same device as your WemoServer use the 'search' menu button and select 'Find new Wemos' whenever you add a new MppDevice, though usually they will be discovered automatically by the WemoServer with no search action.

The AutomationServer uses its REST port for incoming notifications of state changes from MppDevices. The WemoServer REST server must be enabled and operating on the default port 4030 (confirm that the indicator on the AutomationServer widget is green).

AutomationManager

When you are not using the AutomationServer at all you need to install MppDevices on each handset using AutomationManager, and you will need to add the custom devices to each instance. Discovery of your configured devices should be automatic.

If the MppDevices server is installed on a different (dedicated) device, use the 'search' menu 'Find MppDevices' action in WemoServer to find it. Point it to your MppServer IP on port 8898.

AutomationRemote

Drivers Mpp Port Devices Usb

When you're using AutomationRemote with a AutomationServer your custom MppDevices will show up automatically in AutomationRemote once you have configured the AutomationServer/MppDevices pair.





Comments are closed.