An interface device and method of use thereof

Abstract

Figure 1) An interface device for retrofit installation to a controller of a motorised bed is provided for enabling communication between the controller and a voice command device. In one form, the device includes: at least one connector for connecting with a serial port of the controller; a wireless communications module for wirelessly connecting to the controller and the voice command device; and a microcontroller operatively connected to the at least one connector and the wireless communications module. The microcontroller is programmed to: automatically determine how the controller is configured to communicate; receive a control command from the voice command device, said control command corresponding to a voice command issued by a user to the voice command device; translate the control command into a control instruction compatible with the protocol determined; and transmit the control instruction to the controller to actuate a desired movement of the motorised bed.

Description

AN INTERFACE DEVICE AND METHOD OF USE THEREOFTECHNICAL FIELD

[0001] The present invention relates to an interface device and method of use for retrofit installation to a controller of a motorised bed for enabling communication between the controller and a voice command device.BACKGROUND

[0002] Motorised beds, including adjustable beds, profiling beds, and hospital or home-care beds, are widely used in aged-care, disability, rehabilitation, and domestic settings. These beds typically include one or more actuators for adjusting the position of the bed, such as head elevation, foot elevation, bed height, and tilt functions.

[0003] Users with quadriplegia, severe arthritis, Parkinson's disease, motor neurone disease, acquired brain injury, or other conditions affecting dexterity may be unable to operate standard controls reliably or at all. Users with low vision may be unable to locate buttons or identify pictograms on hand controllers. Users with cognitive impairment may be unable to understand pictograms or may frequently misplace hand controllers. Furthermore, in care environments involving manual or machine-assisted transfers into and out of bed, carers may benefit from voice control to operate the bed while keeping both hands and attention on the person being transferred.

[0004] Voice control via voice command devices, such as, e.g., Amazon™ Alexa™, Google™ Assistant, or Apple HomeKit™ offers a potential solution for users with limited hand function. However, the market for motorised bed controllers is fragmented. Different manufacturers use different communication protocols, connector configurations, signal voltages, baud rates, and command formats. Some controllers communicate via wired serial connections, while others use wireless protocols such as Bluetooth Low Energy. There is no industry-wide interoperability standard.

[0005] Existing approaches to voice-enabled bed control are typically manufacturerspecific. They require proprietary gateway hardware, are not easily retrofitted to existing beds, and do not work with controllers from other manufacturers. A user wishing to add voice control to an existing bed may find that no compatible solution is available for their particular bed model.

[0006] Furthermore, the personnel who install and configure assistive technology equipment, such as, e.g., occupational therapists, disability support workers, and community care staff, are generally not trained to identify communication protocols, configure embeddeddevices, or troubleshoot serial versus wireless connectivity. If a voice control solution requires technical configuration, it may not be deployed reliably in real-world care environments.

[0007] It will be clearly understood that, if a prior art publication is referred to herein, this reference does not constitute an admission that the publication forms part of the common general knowledge in the art in Australia or in any other country.SUMMARY OF INVENTION

[0008] Embodiments of the present invention provide an interface device and method of use thereof, which may at least partially address one or more of the problems or deficiencies mentioned above or which may provide the public with a useful or commercial choice.

[0009] According to a first aspect of the present invention, there is provided an interface device for enabling communication between a voice command device and a controller of a motorised bed, said device configured for retrofit installation to the bed for enabling a user to control the bed through voice commands via the voice command device, said interface device including: at least one connector for connecting with a serial port of the controller; a wireless communications module for wirelessly connecting to the controller and the voice command device; a microcontroller operatively connected to the at least one connector and the wireless communications module, said microcontroller including at least one processor and a memory and programmed to: execute a protocol detection sequence to automatically determine whether the controller is configured to communicate via a serial protocol or via a wireless protocol, said detection sequence including transmitting one or more probe signals via the serial port, determining whether a valid response is received, and, if no valid response is received, initiating wireless scanning to discover the controller by identifying devices advertising bed control services; store a result of the protocol detection sequence in the memory; receive a control command from the voice command device, said control command corresponding to a voice command issued by a user to the voice command device; translate the control command into a control instruction compatible with the protocol determined by the protocol detection sequence; and transmit the control instruction to the controller via the determined protocol to actuate a desired movement of the motorised bed.

[0010] Advantageously, the interface device enables voice control of a motorised bed without requiring the user or installer to have knowledge of the communication protocol used by the bed controller. The protocol detection sequence automatically determines whether the controller communicates via a serial port or a wireless protocol and configures the interface device accordingly. This allows the interface device to be installed by non-technical personnel, such as care workers or family members, without specialist training or equipment.

[0011] The interface device may be retrofitted to existing motorised beds regardless of manufacturer, providing a universal or near-universal voice control solution that is independent of proprietary gateway hardware or manufacturer-specific cloud services. By storing the result of the protocol detection sequence in memory, the interface device can reconnect to the bed controller on subsequent power cycles without repeating the detection process.

[0012] The interface device enables users with limited hand function, including users with quadriplegia, arthritis, Parkinson's disease, motor neurone disease, or acquired brain injury, to independently control their bed using voice commands through a voice command device they may already own.

[0013] As indicated above, the interface device of the present invention is for retrofit installation and enabling communication between a voice command device and a controller of a motorised bed, so that the motorised bed may be controlled through voice commands. It will therefore be convenient to describe the device and method with reference to this example application. However, a person skilled in the art will appreciate that the device is capable of broader applications and may be used to interface communications between voice command devices and other motorised furniture, such as, e.g., electric recliners, lift chairs, standing frames, and powered over-bed tables.

[0014] As used herein, the term “voice command device” includes any device capable of receiving and processing voice commands from a user and communicating those commands to other devices.

[0015] Examples of such devices include smart speakers (such as, e.g., Amazon Echo™, Apple HomePod™ and Google Nest™), smart displays, smartphones, tablets and other devices running voice assistant software (such as, e.g., Amazon Alexa™, Apple Siri™ or Google™ Assistant). The voice command device may process voice commands locally or via a cloudbased voice recognition service and may communicate with the interface device via wireless or wired network protocols, preferably wireless network protocols.

[0016] As used herein, a "voice command" received by the interface device refers to astructured digital control command transmitted by the voice command device to the interface device, said control command representing an intent derived from a voice command spoken by a user. The voice command device processes the user's spoken audio, resolves the intent (e.g., via a cloud-based natural language processing service), identifies the target device and action, and transmits a corresponding control command to the interface device via a network protocol such as Matter, Zigbee, Wi-Fi, or Bluetooth Low Energy. The interface device does not receive or process raw audio; rather, it receives a digital command representing the user's intent.

[0017] In some embodiments, the voice command device may be supplemented or replaced by alternative input devices for users who cannot use voice commands. Alternative input devices may include touchscreen interfaces, eye-gaze tracking interfaces, sip-and-puff interfaces, switch scanning interfaces, or other assistive technology input devices. The interface device may receive commands from such alternative input devices via the wireless communications module or via a wired connection.

[0018] As used herein, the term “motorised bed” may include any bed incorporating one or more electrically powered actuators for adjusting a position or configuration of the bed or portions thereof.

[0019] Examples include adjustable beds, profiling beds, hospital beds, home-care beds, aged-care beds and rehabilitation beds.

[0020] Motorised beds may include actuators for head elevation, foot elevation, knee-break adjustment, bed height, Trendelenburg and reverse Trendelenburg positioning, and tilt functions.

[0021] The motorised bed typically includes a hand controller for user operation. The hand controller may be a wired hand controller connected to the controller of the motorised bed via a cable, or a wireless hand controller communicating with the controller via a wireless protocol such as, e.g., Wi-Fi (WLAN) communication, RF communication, infrared communication or Bluetooth Low Energy.

[0022] The controller of the motorised bed may be configured to communicate via a serial port, such as, e.g., a Universal Asynchronous Receiver / Transmitter (“UART”) port, or via a wireless communication protocol.

[0023] Controllers configured for wired hand controllers typically include a serial port for receiving commands.

[0024] Controllers configured for wireless hand controllers typically communicate via a wireless protocol.

[0025] Some controllers may include an accessory port or legacy port that may or may not be active for receiving commands, depending on the controller's configuration.

[0026] As noted above, the market for motorised bed controllers is fragmented. Different manufacturers use different communication protocols, connector configurations, signal voltages, baud rates, and command formats. Even where a controller includes a serial port, the port may use a non-standard baud rate, framing convention, or command set. Similarly, controllers using wireless protocols may implement proprietary services and characteristics. A given bed controller may have a physical serial port present but be configured to accept commands only via a wireless protocol, or vice versa. This fragmentation means that an installer cannot reliably determine, from visual inspection alone, how a particular controller is configured to communicate.

[0027] The interface device may preferably include a body for at least partially housing various device components, including the at least one connector, the at least one wireless communications module and the microcontroller. The body may be of any suitable size, shape and construction.

[0028] Generally, the body may be formed from metal and / or plastic materials, typically plastic. The body may be formed from two or more body pieces, such as, e.g., an upper body piece and a lower body piece that connect together in an edge-to-edge connection.

[0029] As indicated, the device includes at least one connector for connecting with a serial port of the controller of the motorised bed.

[0030] In some embodiments, the at least one connector may include at least one plug extending from the body.

[0031] The at least one plug may include any suitable plug for connecting with the serial port of the controller. The at least one plug may vary depending on a serial port configuration used by a particular bed manufacturer. Examples include RJ-style connectors, DIN connectors, USB connectors, or proprietary multi-pin connectors.

[0032] In some embodiments, the device may include more than one plug. For example, the device may include two plugs, three plugs, four plugs or even five plugs. In such embodiments, the device may include a combination of different plug types enabling the device to be connected to different serial ports of different motorised beds.

[0033] In other embodiments, the at least one plug may be interchangeable with other plug types. For example, the at least one plug may be detachably connected to the device so that itmay be readily interchanged with other plug types.

[0034] In such embodiments, the at least one plug and the device may be connected together by a connecting mechanism or parts thereof. The connecting mechanism or parts thereof may or may not be of integral formation with the device and the at least one plug.

[0035] The connecting mechanism may include a first part associated with a part of the at least one plug and a second part connectable to the first part and associated with the device.

[0036] The connecting mechanism may include mateable male and female portions that couple together, such as, e.g., a threaded connection, an interference (snap-fit) type connection or a bayonet-type connection.

[0037] In some embodiments, the at least one plug and the device may be connectable together by a quick change snap in connector enabling different plug types to be readily interchanged.

[0038] Advantageously, by having more than one plug type or interchangeable plug types, the device may be connectable to a broader range of motorised beds without requiring the installer to source a specific cable or adapter.

[0039] In other embodiments, the at least one connector may include a port for connecting to a serial port of the controller with a suitable cable.

[0040] The port may be of any suitable form for receiving a cable. Examples include RJ- style sockets, DIN sockets, USB sockets, or proprietary multi-pin sockets.

[0041] In such embodiments, the device may be supplied with one or more cables for connecting the port to the serial port of the controller. Each cable may include a first end configured to connect to the port of the device and a second end configured to connect to the serial port of the controller.

[0042] Advantageously, by providing the at least one connector in the form of a port, the device may be positioned at a distance from the controller, with the cable providing the physical connection therebetween. This may facilitate installation in configurations where the device cannot be directly plugged into the controller, such as, e.g., where the controller is located in an inaccessible position beneath the bed or within an enclosure.

[0043] In some embodiments, the device may be supplied with a plurality of cables having different second ends configured for connection to different serial port configurations of differentmotorised bed controllers. This enables a single device to be installed on a variety of motorised beds by selecting an appropriate cable for the particular bed controller.

[0044] As indicated, the device includes at least one communications module for wirelessly connecting to the controller and the voice command device. The communications module may be in the form of a wireless communications module, such as, e.g., a wireless network interface controller, such that the device may wirelessly connect to the controller and the voice command device via a wireless communications network (e.g., Wi-Fi (WLAN) communication, RF communication, infrared communication, or Bluetooth Low Energy).

[0045] In some embodiments, the wireless communications module may include a cellular modem for connecting to a mobile telecommunications network, enabling the device to operate independently of a local wireless network.

[0046] As indicated, the device includes a microcontroller operatively connected to the at least one connector and the wireless communications module. The microcontroller includes at least one processor and a memory.

[0047] The processor may include multiple inputs and outputs coupled to other electronic components of the device, including the at least one connector and the at least one wireless communications module.

[0048] The memory may include stored data thereon corresponding to the protocol detection sequence. Preferably, the memory may include non-volatile memory, such as, e.g., flash memory or EEPROM. Advantageously, non-volatile memory ensures that the result of the protocol detection sequence is retained when the device is powered off. This enables the device to reconnect to the controller on subsequent power cycles without repeating the protocol detection sequence.

[0049] In some embodiments, the device may further include one or more keys, buttons and / or switches for a user to control operation of the device. For example, in some such embodiments, the device may include a button dial.

[0050] The one or more keys, buttons and / or switches may be suitably located on an external surface of the body.

[0051] In some embodiments, the device may include at least one display for displaying information on the motorised bed, the controller and the communication protocol detected and / or determined.

[0052] The display may be of any suitable form. The display may be a liquid crystal display (“LCD”), a plasma display or an LED display. The at least one display may be a colour display.

[0053] In some embodiments, the display may include a touch screen enabling a user to interact with the device via the display.

[0054] The at least one display may be located at any suitable location on the body of the device so as to be readily viewable.

[0055] The device may preferably include a power source for receiving electrical power for at least powering the microcontroller and the at least one wireless communications module.

[0056] In some embodiments, the power source may be the controller with the device configured to receive power via the at least one connector when connected to the serial port.

[0057] In other embodiments, the power source may be an external power source, such as, e.g., a USB power supply, a mains power adapter, or a 12V or 24V auxiliary supply available from the motorised bed.

[0058] In yet other embodiments, the device may be configured to receive power from multiple power sources. For example, the device may be configured to receive power via the at least one connector and / or via an external power source. Advantageously, this enables the device to be powered in a variety of installation configurations depending on the power supply options available at a particular motorised bed.

[0059] The device may preferably include protection circuitry, such as, e.g., reverse polarity protection and / or over-current protection, to protect the device from damage in the event of incorrect connection or a fault condition.

[0060] As indicated, the microcontroller of the device is configured to execute a protocol detection sequence to automatically determine whether the controller is configured to communicate via a serial protocol or via a wireless protocol.

[0061] The protocol detection sequence may be executed upon initial connection of the device to the motorised bed, or upon power-up of the device where no previously stored protocol configuration is present in the memory.

[0062] The protocol detection sequence preferably includes a serial protocol detection phase followed by a wireless protocol detection phase.

[0063] In the serial protocol detection phase, the microcontroller transmits one or moreprobe signals via the at least one connector to the serial port of the controller. If the at least one connector is not connected to a serial port, or if the serial port is inactive, the microcontroller will not receive a valid response and will proceed to the wireless protocol detection phase. The probe signals may include one or more probe frames configured to elicit a response from the controller if the controller is configured to communicate via a serial protocol.

[0064] The probe frame may include a start byte, a function or command byte, one or more parameter bytes, and a checksum or error detection byte. The specific format of the probe frame may vary depending on common conventions used by bed controller manufacturers.

[0065] The microcontroller monitors the serial port for a valid response from the controller within a predetermined timeout period, such as, e.g., 500 milliseconds to 2,000 milliseconds.

[0066] If a valid response is received, the microcontroller may determine that the controller is configured to communicate via a serial protocol and may store this result in the memory. The device may then enter serial communication mode for subsequent communication with the controller.

[0067] In some embodiments, the serial protocol detection phase may include automatic baud rate detection. The microcontroller may transmit probe signals at a plurality of different baud rates, such as, e.g., 9600, 19200, 38400, 57600, or 115200 bits per second, and determine the baud rate at which a valid response is received. The detected baud rate may be stored in the memory for subsequent communication.

[0068] In some embodiments, the microcontroller may detect the baud rate by measuring a duration of a start bit on a receive line of the serial port. This enables the microcontroller to determine the baud rate used by the controller without requiring prior knowledge of the baud rate.

[0069] If no valid response is received via the serial port after one or more probe attempts, the microcontroller proceeds to the wireless protocol detection phase.

[0070] In the wireless protocol detection phase, the microcontroller initiates wireless scanning via the wireless communications module to discover the controller.

[0071] The wireless scanning may include scanning for devices using one or more wireless protocols, such as, e.g., Bluetooth Low Energy (BLE), Wi-Fi, Zigbee, Z-Wave, Thread, or proprietary RF protocols.

[0072] In embodiments where the wireless scanning includes a Bluetooth Low Energy(BLE) scan, the wireless communications module may operate in central mode and scan for peripheral devices advertising bed control services.

[0073] In embodiments where the wireless scanning includes a Wi-Fi scan, the wireless communications module may scan for devices on a local network that advertise bed control services, such as, e.g., via mDNS (multicast DNS), SSDP (Simple Service Discovery Protocol), or Matter discovery protocols.

[0074] In embodiments where the wireless scanning includes a Zigbee, Z-Wave, or Thread scan, the wireless communications module may scan for devices on a mesh network that expose bed control functionality.

[0075] The microcontroller may filter discovered devices by one or more criteria, such as, e.g., advertised service identifiers, device names, manufacturer data patterns, device type identifiers, or signal strength, to identify devices that are likely to be bed controllers.

[0076] Upon identifying a candidate device, the microcontroller may initiate a connection to the device and perform service discovery to determine whether the device exposes services and characteristics consistent with bed control functionality.

[0077] For BLE devices, service discovery may include performing GATT (Generic Attribute Profile) service discovery to identify one or more writable characteristics for transmitting control instructions to the controller, and optionally one or more notify or indicate characteristics for receiving status information from the controller.

[0078] In embodiments where the wireless protocol is Bluetooth Low Energy, the microcontroller may negotiate a Maximum Transmission Unit (MTU) with the controller upon establishing a connection. The negotiated MTU may be in the range of 185 to 247 bytes, enabling efficient transmission of control instructions and status information in a single packet.

[0079] The microcontroller may configure connection parameters for the BLE connection with the controller. The connection parameters may include a connection interval, such as, e.g., 30 milliseconds, and a supervision timeout, such as, e.g., 4000 milliseconds. The connection interval determines the frequency at which the interface device and controller exchange data packets. The supervision timeout determines the period after which a connection is considered lost if no packets are received.

[0080] In some embodiments, the microcontroller may store one or more bond keys in the non-volatile memory following a pairing or bonding procedure with the controller. The bond keys enable the interface device to re-establish a secure connection with the controller on subsequentpower cycles without requiring the user to repeat the pairing procedure. The bond keys may include one or more of a Long Term Key (LTK), Identity Resolving Key (IRK), or Connection Signature Resolving Key (CSRK).

[0081] For Wi-Fi, Zigbee, Z-Wave, Thread, or Matter-compatible devices, service discovery may include querying the device for supported endpoints, clusters, or control interfaces.

[0082] If a suitable bed controller is discovered and connected, the microcontroller stores the wireless protocol configuration in the memory, including, e.g., the protocol type, device address, service identifiers, and any characteristic handles or endpoint identifiers required for subsequent communication. The device then enters wireless communication mode for subsequent communication with the controller.

[0083] If no suitable bed controller is discovered during the wireless protocol detection phase, the microcontroller may retry the protocol detection sequence, enter a standby or error state, or alert the user via the display or other indicator.

[0084] Advantageously, by attempting serial protocol detection before wireless protocol detection, the device prioritises wired communication where available, which may provide more reliable and lower-latency communication with the controller.

[0085] In some embodiments, the device may be configured to re-execute the protocol detection sequence upon detecting a loss of communication with the controller. This enables the device to automatically reconfigure itself if it is moved to a different motorised bed or if the controller configuration changes.

[0086] As indicated, the microcontroller is programmed to receive a control command from the voice command device and translate the control command into a control instruction compatible with the protocol determined by the protocol detection sequence.

[0087] Control commands received from the voice command device may be in the form of semantic intents representing desired bed movements or positions. Examples of semantic intents include "head up", "head down", "foot up", "foot down", "raise head", "lower head", "raise foot", "lower foot", "flat", "zero gravity", "lounge", "anti-snore", "TV position", "cardiac chair", "Trendelenburg", "reverse Trendelenburg", "height up", "height down", "memory position 1", "memory position 2", "stop", or similar commands.

[0088] The microcontroller may normalise received control commands into a set of controller-independent semantic codes. For example, variations such as "raise head", "head up", "lift the head", and "tilt the head up" may all be normalised to a single semantic code suchas "HEADJJP".

[0089] The microcontroller may store in the memory a translation table mapping semantic codes to protocol-specific control instructions for one or more bed controller types.

[0090] The translation table may include, for each supported bed controller type, a mapping between each semantic code and a corresponding protocol-specific payload. For serial protocol controllers, the payload may include a sequence of bytes comprising, e.g., a start byte, a command byte, one or more parameter bytes, and a checksum or error detection byte. For wireless protocol controllers, the payload may include a characteristic handle and a value to be written to that characteristic, or an endpoint identifier and a command to be transmitted to that endpoint.

[0091] For example, a translation table entry for a "HEAD_UP" command may include: for a first serial protocol controller, a byte sequence such as OxAA 0x10 0x01 0x11; for a second serial protocol controller, a different byte sequence such as 0x550x01 OxOA 0x60; and for a BLE controller, a characteristic handle and a value such as 0x01 to be written thereto.

[0092] Advantageously, the translation table architecture enables a single interface device to support multiple bed controller types without requiring hardware modifications. New bed controller types may be supported by updating the translation table, such as, e.g., via a firmware update.

[0093] In some embodiments, the translation table may be stored in the non-volatile memory of the microcontroller and may be updated via a firmware update received over the wireless communications module.

[0094] In some embodiments, the microcontroller may automatically select an appropriate translation table entry based on the protocol type and controller identifier determined during the protocol detection sequence.

[0095] In some embodiments, the microcontroller may identify the specific bed controller type during the protocol detection sequence by analysing response frames received from the controller, advertised service identifiers, manufacturer data, or other identifying information. The identified controller type may be stored in the memory and used to select the appropriate translation table entry for subsequent command translation.

[0096] In some embodiments, the translation table may include default or generic entries for controllers that are not specifically identified, enabling the device to attempt communication with previously unknown controller types using common command formats.

[0097] In some embodiments, the microcontroller may be configured to communicate with a remote server via the wireless communications module to obtain translation data for the detected controller. Upon detecting a controller type during the protocol detection sequence, the microcontroller may transmit controller identification data to the remote server. The controller identification data may include one or more of: a controller model identifier, a manufacturer identifier, protocol parameters detected during the protocol detection sequence, response signatures, advertised service identifiers, or other identifying information.

[0098] The remote server may return protocol-specific translation data for the identified controller type. The translation data may include mappings between semantic control commands and protocol-specific payloads, timing parameters, handshaking requirements, or other information required to communicate with the identified controller type.

[0099] The translation data received from the remote server may be stored in the nonvolatile memory of the device for subsequent use. Alternatively, or additionally, the device may query the remote server in real-time for each command translation, such that the translation occurs at the remote server rather than locally on the microcontroller.

[0100] In some embodiments, the remote server may maintain a protocol library that is updated based on data received from a plurality of interface devices deployed in the field. For example, when an interface device successfully detects and establishes communication with a previously unknown controller type, the device may transmit protocol parameters, response signatures, command-response pairs, or other protocol characterisation data to the remote server.

[0101] The remote server may analyse the received data to characterise the previously unknown controller type and generate translation data for that controller type. The generated translation data may be added to the protocol library maintained by the remote server, enabling support for the previously unknown controller type across all deployed interface devices.

[0102] Advantageously, this cumulative protocol learning architecture enables the protocol library to grow over time as interface devices encounter new controller types in the field. Updated protocol data may be distributed to other interface devices via firmware updates, realtime queries, or periodic synchronisation.

[0103] In some embodiments, the device may operate in a hybrid mode in which commonly- used translation data is stored locally in the non-volatile memory, while less common or newly- added controller protocols are retrieved from the remote server as needed. The device may cache translation data retrieved from the remote server in the non-volatile memory forsubsequent use.

[0104] Advantageously, hybrid operation reduces latency for common operations while enabling support for a broad and evolving range of controller types. The device may operate in a degraded local-only mode if connectivity to the remote server is temporarily unavailable, using locally cached translation data.

[0105] In some embodiments, the remote server may transmit configuration parameters to the device in addition to translation data. The configuration parameters may include safety parameters, timing parameters, feature flags, or other operational parameters. The device may apply received configuration parameters to modify its operation without requiring a firmware update.

[0106] Advantageously, the command translation architecture enables the interface device to provide a consistent voice command interface to the user regardless of the underlying bed controller type or communication protocol. The user may issue the same voice commands (e.g., "raise head", "lower foot", "go flat") regardless of whether the bed controller uses a serial or wireless protocol, and regardless of the specific command format required by that controller.

[0107] In some embodiments, the microcontroller may be programmed to receive status information from the controller and transmit the status information to the voice command device or a smart home platform.

[0108] The status information may include one or more of: a current position of the bed (e.g., head elevation angle, foot elevation angle, bed height), a status of one or more actuators (e.g., moving, stationary, fault condition), a connection status with the controller, or other operational parameters.

[0109] In some embodiments, the interface device may receive bed position or status information from sources other than the controller. For example, the interface device may receive position information from one or more sensors attached to the bed or to the interface device itself, such as, e.g., accelerometers, gyroscopes, or Hall effect sensors. In other embodiments, the interface device may receive position or occupancy information from external sensing systems, such as, e.g., video cameras, radar, lidar, infrared beam sensors, or pressure sensors. The interface device may integrate position or status information from multiple sources to provide a more complete or accurate representation of the bed state to the voice command device or smart home platform.

[0110] For serial protocol controllers, the microcontroller may receive status information inresponse frames transmitted by the controller following a control instruction or in response to a status query transmitted by the microcontroller. For wireless protocol controllers, the microcontroller may receive status information via notify or indicate characteristics, or by reading status characteristics from the controller.

[0111] The microcontroller may translate the received status information into a format compatible with the voice command device or smart home platform, such as, e.g., a standardised smart home device state representation. This enables the user to query the current bed position via voice command (e.g., "What position is my bed in?") or view the bed status in a smart home application.

[0112] Advantageously, bidirectional communication between the interface device and the voice command device or smart home platform enables the user to monitor the status of the motorised bed and provides confirmation that voice commands have been successfully executed.

[0113] The microcontroller may be programmed to implement one or more safety features to ensure safe operation of the motorised bed.

[0114] In some embodiments, the microcontroller may implement a safety timeout that terminates actuator movement if an acknowledgment or response is not received from the controller within a predetermined timeout period. For example, the microcontroller may transmit a control instruction to the controller and monitor for an acknowledgment. If no acknowledgment is received within a timeout period, such as, e.g., 1.5 to 2.0 seconds, the microcontroller may automatically transmit a stop command to the controller to terminate actuator movement.

[0115] Advantageously, the safety timeout prevents indefinite actuator drive in the event of a communication failure, cable disconnection, or other fault condition.

[0116] In some embodiments, the microcontroller may implement command queuing to manage multiple control commands received in succession. The command queue may enforce serial execution of commands, such that only one actuator movement command is active at any given time.

[0117] When a new control command is received while a previous command is still being executed, the microcontroller may terminate the active command by transmitting a stop command to the controller and then execute the newly received command. This prevents mechanical conflicts, such as, e.g., simultaneous head-up and head-down commands, or head elevation occurring while height adjustment is still in progress.

[0118] In some embodiments, the microcontroller may monitor transmission activity on the serial port and automatically force the serial interface to a high-impedance state if transmission exceeds a predetermined timeout threshold. This protects against stuck-low transmission lines, short circuits, or mis-wired connectors.

[0119] In some embodiments, the microcontroller may validate received response frames using a checksum or cyclic redundancy check (CRC) to ensure data integrity. Invalid frames may be discarded, and the microcontroller may retry the transmission or alert the user to a communication error.

[0120] In some embodiments, the microcontroller may implement a watchdog timer that resets the microcontroller if the firmware becomes unresponsive. This ensures that the device recovers from unexpected software faults without requiring manual intervention.

[0121] In some embodiments, the device may include one or more status indicators, such as, e.g., LEDs or display messages, to indicate the operational status of the device, including, e.g., power status, connection status, communication errors, or fault conditions.

[0122] In some embodiments, the device may be configured to transmit a stop command to the controller upon detecting a loss of communication with the voice command device or the controller. This ensures that actuator movement is terminated if the communication link is interrupted.

[0123] In some embodiments, the device may store one or more safety parameters in the non-volatile memory, such as, e.g., timeout durations, maximum movement durations, or permitted command sequences. The safety parameters may be configurable via a firmware update or a configuration interface.

[0124] Advantageously, the safety features implemented by the device help to ensure safe operation of the motorised bed, particularly in care environments where users may have limited ability to respond to unexpected bed movements or fault conditions.

[0125] In some embodiments, the device may include a configuration interface for enabling a user to manually configure or override the protocol detection result.

[0126] The configuration interface may be in the form of a web portal accessible via a wireless connection to the device. In such embodiments, the device may operate as a wireless access point or connect to a local wireless network, and the user may access the web portal using a web browser on a smartphone, tablet, or computer.

[0127] Alternatively, or additionally, the configuration interface may be in the form of a commissioning screen displayed on the display of the device. The user may interact with the commissioning screen via the touch screen or via the one or more keys, buttons and / or switches.

[0128] The configuration interface may enable the user to manually select a communication protocol (e.g., serial or wireless), select a specific bed controller type from a list of supported controllers, enter or modify connection parameters (e.g., baud rate, device address, service identifiers), initiate a re-scan for available controllers, or reset the device to factory defaults.

[0129] In some embodiments, the configuration interface may include a web-based control panel enabling direct control of bed actuators via a browser interface. The web-based control panel may be provided by a web server hosted by the microcontroller, or by a remote server in communication with the device via the wireless communications module.

[0130] In embodiments where the web server is hosted by the microcontroller, a user may access the configuration interface by navigating to an IP address or hostname of the device on a local network. In embodiments where the web server is hosted by a remote server, the user may access the configuration interface by navigating to a URL of the remote server and authenticating to access the device. Advantageously, where the configuration interface is provided by a remote server, the configuration interface may be accessible from any internet- connected device without requiring the user to be on the same local network as the interface device.

[0131] Advantageously, web-based actuator control enables an installer, technician, or user to test bed functionality without requiring voice commands or a paired voice command device. The control panel may also be used to verify correct operation following installation or maintenance.

[0132] In some embodiments, the configuration interface may enable per-user calibration of motor run times. For example, an occupational therapist, carer, or installer may configure the duration of motor activation for each actuator function to suit the needs of a particular user. The calibrated run times may be stored in the non-volatile memory and applied when executing control commands.

[0133] For example, a user with limited mobility may require longer activation times to achieve a comfortable position, while a user with sensitivity to rapid movement may require shorter activation times with pauses between movements. The per-user calibration enables the device to be tailored to individual user needs without modifying the underlying firmware.

[0134] In some embodiments, the configuration interface may enable configuration of personalised positions. For example, a user or carer may define one or more custom positions specifying target angles or percentages for each actuator and associate each custom position with a voice command label such as "my reading position", "sleep position", or "transfer position".

[0135] The personalised positions may be stored in the non-volatile memory and recalled via voice commands or via the web-based control panel. Advantageously, position personalisation enables users to store and recall positions suited to their individual needs without requiring manual adjustment each time.

[0136] In some embodiments, the configuration interface may enable configuration of therapy-specific movement sequences. A movement sequence may comprise a series of position changes executed automatically at defined intervals.

[0137] For example, for pressure injury prevention, the configuration interface may enable configuration of periodic micro-adjustments at defined intervals, such as a small position change every 15 minutes, 30 minutes, or other clinically appropriate interval. The movement sequence may include dwell timing parameters specifying how long the bed should remain in each position before the next adjustment.

[0138] In other examples, the configuration interface may enable configuration of movement sequences for other therapeutic purposes, such as postural drainage, circulation promotion, or sleep cycle optimisation. The movement sequences may be configured by a healthcare professional and stored in the non-volatile memory for automatic execution.

[0139] In some embodiments, the configuration interface may enable configuration of movement limits for safety or risk management purposes. For example, maximum head elevation angles, maximum height settings, maximum tilt angles, or restricted movement combinations may be configured to suit a particular user's clinical needs.

[0140] The movement limits may be stored in the non-volatile memory and enforced by the microcontroller when executing control commands. If a control command would result in movement beyond a configured limit, the microcontroller may terminate the movement at the limit, refuse to execute the command, or alert the user or carer.

[0141] Advantageously, configurable movement limits enable healthcare professionals to configure the device to prevent potentially harmful movements for users with specific clinical conditions, such as spinal injuries, respiratory conditions, or post-surgical restrictions.

[0142] In some embodiments, the device may maintain a diagnostic log recordingoperational events, errors, usage data, and other information. The diagnostic log may be stored in the non-volatile memory and may include timestamps, event types, error codes, command histories, communication statistics, or other diagnostic information.

[0143] The configuration interface may enable viewing of the diagnostic log and uploading of log data to the remote server for analysis. Advantageously, diagnostic log upload enables remote troubleshooting, fault identification, and fleet-wide monitoring without requiring physical access to the device.

[0144] In some embodiments, the device may be configured to receive over-the-air (OTA) firmware updates via the wireless communications module. The device may periodically check for available updates from the remote server, or an installer or technician may manually initiate an update via the configuration interface.

[0145] Firmware updates may include updated translation tables, new controller protocol support, updated safety features, bug fixes, new configuration options, or other improvements. The device may verify the integrity and authenticity of firmware updates before applying them, such as by verifying a digital signature or checksum.

[0146] Advantageously, OTA firmware updates enable the device to be improved and maintained without requiring physical access or replacement, supporting ongoing service delivery and protocol library expansion.

[0147] In some embodiments, the device may be configured to enable remote support by a technician or support personnel. The configuration interface may include a remote access feature enabling authorised personnel to view device status, diagnostic logs, and configuration settings, and to modify settings remotely.

[0148] Remote access may be initiated by the user or carer via the configuration interface or may be initiated by the technician with appropriate authorisation. The remote access session may be secured using encryption, authentication tokens, or other security measures.

[0149] Advantageously, remote support enables technician-free commissioning, remote troubleshooting, and ongoing support without requiring site visits. This reduces service costs and enables faster resolution of issues, particularly for devices deployed in remote or distributed locations.

[0150] In some embodiments, a plurality of interface devices may be registered with a remote fleet management server. The fleet management server may aggregate diagnostic data, usage statistics, firmware status, configuration status, and other information across all registereddevices.

[0151] The fleet management server may provide a dashboard or interface enabling an administrator to monitor the status of all registered devices, identify devices requiring attention, schedule firmware updates, generate reports, or perform other fleet-wide management functions.

[0152] Advantageously, fleet management enables organisations deploying multiple interface devices, such as aged care providers, disability service providers, or equipment hire companies, to efficiently manage and maintain their deployed devices from a central location.

[0153] Advantageously, the configuration interface provides a manual override capability for installations where the automatic protocol detection sequence does not successfully identify the controller, or where the user wishes to select a specific configuration.

[0154] In some embodiments, the device may include a voltage level shifting circuit for translating signal voltages between the microcontroller and the serial port of the controller.

[0155] The microcontroller may operate at a first logic voltage level, such as, e.g., 3.3V, while the serial port of the controller may operate at a second logic voltage level, such as, e.g., 5V. The voltage level shifting circuit enables bidirectional communication between the microcontroller and the controller notwithstanding the difference in logic voltage levels.

[0156] In some embodiments, the voltage level shifting circuit may include one or more N- channel MOSFET devices configured for bidirectional level translation. Each MOSFET device may be connected between a transmit or receive line of the microcontroller and a corresponding line of the serial port.

[0157] The voltage level shifting circuit may include pull-up resistors connected to respective logic voltage rails. For example, a first pull-up resistor may be connected between the microcontroller side of the MOSFET and a 3.3V supply rail, and a second pull-up resistor may be connected between the controller side of the MOSFET and a 5V supply rail. The pull- up resistors may have a resistance of, e.g., 10kQ.

[0158] In operation, when the transmit or receive line on either side of the MOSFET is pulled low, the MOSFET conducts and pulls the corresponding line on the other side low. When the line is released, the pull-up resistors return both sides to their respective high logic levels.

[0159] Advantageously, this arrangement permits the transmit and receive lines to idle high in both voltage domains and to be pulled low by either side without contention. The bidirectionalnature of the circuit enables both transmission and reception of serial data without requiring separate level shifting circuits for each direction.

[0160] In other embodiments, the voltage level shifting circuit may include dedicated level shifting integrated circuits, voltage dividers, or other level translation arrangements known in the art.

[0161] In some embodiments, the voltage level shifting circuit may be configured to support a range of controller logic voltages, such as, e.g., 3.3V, 5V, or 12V, enabling the device to interface with controllers operating at different voltage levels.

[0162] According to a second aspect of the present invention, there is provided a retrofit kit for providing voice control to an existing motorised bed, said kit including: an interface device according to the first aspect; and a plurality of interchangeable plugs or cables adapted for connection to different serial port configurations of different motorised bed controllers.

[0163] The retrofit kit may include one or more features or characteristics of the device as hereinbefore described.

[0164] According to a third aspect of the present invention, there is provided a system for voice control of a motorised bed, said system including: an interface device according to the first aspect; a controller of the motorised bed connected to the interface device via the serial port or communicating wirelessly with the wireless communications module; and a voice command device connected to the interface device via a network, wherein control commands corresponding to voice commands received at the voice command device are transmitted to the interface device, translated into protocol-specific control instructions, and delivered to the controller to actuate positioning functions of the motorised bed.

[0165] The system may include one or more features or characteristics of the device as hereinbefore described.

[0166] According to a fourth aspect of the present invention, there is provided a system including: an interface device according to the first aspect; a remote server configured to receive controller identification data from the device and return protocol-specific translation data, wherein the remote server maintains a protocol library that is updated based on datareceived from a plurality of deployed devices.

[0167] The system may include one or more features or characteristics of the device as hereinbefore described.

[0168] According to a fifth aspect of the present invention, there is provided a system including: a plurality of interface devices according to the first aspect; and a fleet management server configured to aggregate diagnostic data and manage firmware updates across the plurality of devices.

[0169] The system may include one or more features or characteristics of the device as hereinbefore described.

[0170] According to a sixth aspect of the present invention, there is provided a method of enabling communication between a voice command device and a controller of a motorised bed, said method including: connecting an interface device to the bed, said interface device including at least one connector for connecting with a serial port of the controller, a wireless communications module for wirelessly connecting to the controller and the voice command device, and a microcontroller operatively connected to the at least one connector and the wireless communications module; executing a protocol detection sequence to automatically determine whether the controller is configured to communicate via a serial protocol or a wireless protocol, said detection sequence including transmitting one or more probe signals via the serial port, determining whether a valid response is received, and, if no valid response is received, initiating wireless scanning to discover the controller by identifying devices advertising bed control services; storing a result of the protocol detection sequence in a memory of the microcontroller; receiving a control command from the voice command device, said control command corresponding to a voice command issued by a user to the voice command device; translating the control command into a control instruction compatible with the protocol determined by the protocol detection sequence; and transmitting the control instruction to the controller via the determined protocol to actuate a desired movement of the motorised bed.

[0171] The method may include one or more features or characteristics of the interface device as hereinbefore described.

[0172] The method may include connecting the at least one connector of the interface device to a serial port of the controller, where such a serial port is present and accessible. In embodiments where the controller does not include an accessible serial port, the at least one connector may remain unconnected.

[0173] The method may include powering the interface device from a power source. The power source may be the controller, with the interface device receiving power via the at least one connector when connected to the serial port. Alternatively, or additionally, the power source may be an external power source, such as, e.g., a USB power supply, a mains power adapter, or a 12V or 24V auxiliary supply available from the motorised bed.

[0174] The method may include executing the protocol detection sequence upon initial connection of the interface device to the motorised bed, or upon power-up of the interface device where no previously stored protocol configuration is present in the memory.

[0175] The method may include, in the serial protocol detection phase, transmitting one or more probe signals at a plurality of different baud rates to automatically detect a baud rate used by the controller.

[0176] The method may include, in the wireless protocol detection phase, scanning for devices using one or more wireless protocols, such as, e.g., Bluetooth Low Energy (BLE), WiFi, Zigbee, Z-Wave, Thread, or proprietary RF protocols.

[0177] The method may include filtering discovered devices by one or more criteria, such as, e.g., advertised service identifiers, device names, manufacturer data patterns, device type identifiers, or signal strength, to identify devices that are likely to be bed controllers.

[0178] The method may include performing service discovery upon identifying a candidate device to determine whether the device exposes services and characteristics consistent with bed control functionality.

[0179] The method may include normalising received control commands into controllerindependent semantic codes and translating the semantic codes into protocol-specific control instructions using a translation table stored in the memory.

[0180] The method may include implementing one or more safety features, such as, e.g., a safety timeout that terminates actuator movement if an acknowledgment is not received within a predetermined timeout period, or command queuing that enforces serial execution of commands.

[0181] The method may include re-executing the protocol detection sequence upon detecting a loss of communication with the controller, enabling the interface device to automatically reconfigure itself if it is moved to a different motorised bed or if the controller configuration changes.

[0182] According to a seventh aspect of the present invention, there is provided a method of operating an interface device for a motorised bed, the method including: detecting a controller of the motorised bed using a protocol detection sequence; transmitting controller identification data to a remote server; receiving translation data from the remote server; and using the translation data to translate control commands into control instructions compatible with the detected controller.

[0183] The method may include one or more features or characteristics of the interface device as hereinbefore described.

[0184] According to an eighth aspect of the present invention, there is provided a method of updating a protocol library for motorised bed controllers, the method including: receiving, at a remote server, protocol detection data from a first interface device, the protocol detection data characterising a controller type detected by the first interface device; generating translation data for the detected controller type based on the received protocol detection data; storing the generated translation data in a protocol library; and distributing the generated translation data to a second interface device

[0185] The method may include one or more features or characteristics of the interface device as hereinbefore described.

[0186] Any of the features described herein can be combined in any combination with any one or more of the other features described herein within the scope of the invention.

[0187] The reference to any prior art in this specification is not and should not be taken as an acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge.BRIEF DESCRIPTION OF DRAWINGS

[0188] Preferred features, embodiments and variations of the invention may be discerned from the following Detailed Description which provides sufficient information for those skilled in the art to perform the invention. The Detailed Description is not to be regarded as limiting thescope of the preceding Summary of Invention in any way. The Detailed Description will make reference to a number of drawings as follows:

[0189] Figure 1 is a schematic showing an interface device for enabling communication between a voice command device and a controller of a motorised bed, according to an embodiment of the present invention;

[0190] Figure 2 illustrates a protocol detection sequence (200) used by the interface device, as shown in Figure 1 ; and

[0191] Figure 3 illustrates a method for enabling communication between a voice command device and a controller of a motorised bed, according to another embodiment of the present invention.DETAILED DESCRIPTION

[0192] Figure 1 illustrates a schematic showing an interface device (100) for enabling communication between a voice command device (800) and a controller (700) of a motorised bed (900), said device (100) configured for retrofit installation to the bed (900) for enabling a user (500) to control the bed (900) through voice commands via the voice command device (800), said interface device (100) including: at least one connector (110) for connecting with a serial port of the controller (700); a wireless communications module (130) for wirelessly connecting to the controller (700) and the voice command device (800); a microcontroller (150) operatively connected to the at least one connector (110) and the wireless communications module (130), said microcontroller (150) including at least one processor (155) and a memory (158) and programmed to: execute a protocol detection sequence to automatically determine whether the controller (700) is configured to communicate via a serial protocol or via a wireless protocol, said detection sequence including transmitting one or more probe signals via the serial port, determining whether a valid response is received, and, if no valid response is received, initiating wireless scanning to discover the controller (700) by identifying devices advertising bed control services; store a result of the protocol detection sequence in the memory (158); receive a control command from the voice command device (800), said control command corresponding to a voice command issued by a user (500) to the voice command device (800); translate the control command into a control instruction compatible with the protocol determined by the protocol detection sequence; and transmit the control instruction to the controller (700) via the determined protocol to actuate a desired movement of the motorised bed (900).

[0193] The interface device (100) is retrofitted to existing motorised beds regardless of manufacturer, providing a universal or near-universal voice control solution that is independentof proprietary gateway hardware or manufacturer-specific cloud services. By storing the result of the protocol detection sequence in memory (158), the interface device (100) reconnects to the bed controller (700) on subsequent power cycles without repeating the detection process.

[0194] The interface device (100) enables users (500) with limited hand function, including users with quadriplegia, arthritis, Parkinson's disease, motor neurone disease, or acquired brain injury, to independently control their bed (900) using voice commands through a voice command device (800) they may already own.

[0195] The voice command device (800) may be smart speakers (such as, e.g., Amazon Echo™, Apple HomePod™ and Google Nest™), smart displays, smartphones, tablets and other devices running voice assistant software (such as, e.g., Amazon Alexa™, Apple Siri™ or Google™ Assistant). The voice command device (800) processes voice commands locally or via a cloud-based voice recognition service and communicates with the interface device (100) via wireless or wired network protocols, preferably wireless network protocols.

[0196] A "voice command" received by the interface device (100) refers to a structured digital control command transmitted by the voice command device (800) to the interface device (100), said control command representing an intent derived from a voice command spoken by a user (500). The voice command device (800) processes the user's spoken audio, resolves the intent (e.g., via a cloud-based natural language processing service), identifies the target device and action, and transmits a corresponding control command to the interface device (100) via a network protocol such as Matter, Zigbee, Wi-Fi, or Bluetooth Low Energy. The interface device (100) does not receive or process raw audio; rather, it receives a digital command representing the user's intent.

[0197] The motorised bed (900) may include any bed incorporating one or more electrically powered actuators for adjusting a position or configuration of the bed or portions thereof. Examples include adjustable beds, profiling beds, hospital beds, home-care beds, aged-care beds and rehabilitation beds.

[0198] Referring to Figure 1 , the motorised bed (900) includes the hand controller (700) for user operation. The hand controller is a wired hand controller connected to the controller of the motorised bed via a cable.

[0199] The controller (700) of the motorised bed (900) is configured to communicate via a serial port, such as, e.g., a Universal Asynchronous Receiver / Transmitter (“UART”) port, or via a wireless communication protocol.

[0200] The interface device (100) includes a body (190) for at least partially housing various device components, including the at least one connector (110), the at least one wireless communications module (130) and the microcontroller (150).

[0201] Still referring to Figure 1, the device (100) includes at least one connector (110) for connecting with a serial port of the controller (700) of the motorised bed (900).

[0202] The at least one connector (110) includes at least one plug extending from the body. The at least one plug varies depending on a serial port configuration used by a particular bed manufacturer. Examples include RJ-style connectors, DIN connectors, USB connectors, or proprietary multi-pin connectors.

[0203] Alternatively, the device (100) may include a combination of different plug types enabling the device (100) to be connected to different serial ports of different motorised beds.

[0204] Still referring to Figure 1 , the device (100) includes at least one communications module (130) for wirelessly connecting to the controller (700) and the voice command device (800). The communications module (130) is in the form of a wireless communications module, such as, e.g., a wireless network interface controller, such that the device (100) can wirelessly connect to the controller (700) and the voice command device (800) via a wireless communications network (e.g., Wi-Fi (WLAN) communication, RF communication, infrared communication, or Bluetooth Low Energy).

[0205] The wireless communications module (130) also includes a cellular modem for connecting to a mobile telecommunications network, enabling the device (100) to operate independently of a local wireless network.

[0206] Referring to Figure 1, the device (100) includes a microcontroller (150) operatively connected to the at least one connector (110) and the wireless communications module (130). The microcontroller (150) includes at least one processor (155) and a memory (158).

[0207] The processor (155) includes multiple inputs and outputs coupled to other electronic components of the device (100), including the at least one connector (110) and the at least one wireless communications module (130).

[0208] The memory (158) includes stored data thereon corresponding to the protocol detection sequence. The memory (158) includes non-volatile memory, such as, e.g., flash memory or EEPROM. Advantageously, non-volatile memory ensures that the result of the protocol detection sequence is retained when the device (100) is powered off. This enables the device (100) to reconnect to the controller (700) on subsequent power cycles without repeatingthe protocol detection sequence.

[0209] The device (100) includes a power source (180) for receiving electrical power for at least powering the microcontroller (150) and the at least one wireless communications module (130).

[0210] The power source is an external power source, such as, e.g., a USB power supply.

[0211] The device (100) further includes protection circuitry, such as, e.g., reverse polarity protection and / or over-current protection, to protect the device (100) from damage in the event of incorrect connection or a fault condition.

[0212] The microcontroller (150) of the device (100) is configured to execute a protocol detection sequence to automatically determine whether the controller (700) is configured to communicate via a serial protocol or via a wireless protocol.

[0213] The protocol detection sequence may be executed upon initial connection of the device (100) to the motorised bed (900), or upon power-up of the device (100) where no previously stored protocol configuration is present in the memory (158).

[0214] Figure 2 illustrates a protocol detection sequence (200) according to an embodiment of the present invention.

[0215] Referring to Figure 2, the protocol detection sequence (200) includes a serial protocol detection phase (210) followed by a wireless protocol detection phase (220).

[0216] In the serial protocol detection phase (210), the microcontroller (150) transmits one or more probe signals via the at least one connector (110) to the serial port of the controller (700) at step 211. At step 212, if the at least one connector (110) is not connected to a serial port, or if the serial port is inactive, the microcontroller (150) will not receive a valid response and will proceed to the wireless protocol detection phase (220). The probe signals include one or more probe frames configured to elicit a response from the controller (700) if the controller (700) is configured to communicate via a serial protocol.

[0217] The probe frame includes a start byte, a function or command byte, one or more parameter bytes, and a checksum or error detection byte.

[0218] The microcontroller (150) monitors the serial port for a valid response from the controller (700) within a predetermined timeout period, such as, e.g., 500 milliseconds to 2,000 milliseconds.

[0219] At step 213, if a valid response is received, the microcontroller (150) determines that the controller (700) is configured to communicate via a serial protocol and stores this result in the memory (158). The device (100) then enters serial communication mode for subsequent communication with the controller (700) at step 214.

[0220] If no valid response is received via the serial port after one or more probe attempts, the microcontroller (150) proceeds to the wireless protocol detection phase (220).

[0221] In the wireless protocol detection phase (220), the microcontroller (150) initiates wireless scanning via the wireless communications module (130) to discover the controller (700) at step 221.

[0222] The wireless scanning includes scanning for devices using one or more wireless protocols, such as, e.g., Bluetooth Low Energy (BLE), Wi-Fi, Zigbee, Z-Wave, Thread, or proprietary RF protocols.

[0223] At step 222, the microcontroller (150) can filter discovered devices by one or more criteria, such as, e.g., advertised service identifiers, device names, manufacturer data patterns, device type identifiers, or signal strength, to identify devices that are likely to be bed controllers (700).

[0224] At step 223, upon identifying a candidate device, the microcontroller (150) initiates a connection to the device and perform service discovery to determine whether the device exposes services and characteristics consistent with bed control functionality.

[0225] At step 224, if a suitable bed controller is discovered and connected, the microcontroller (150) stores the wireless protocol configuration in the memory (158) at step 225, including, e.g., the protocol type, device address, service identifiers, and any characteristic handles or endpoint identifiers required for subsequent communication. The device (100) then enters wireless communication mode for subsequent communication with the controller (700) at step 226.

[0226] At step 227, if no suitable bed controller is discovered during the wireless protocol detection phase (220), the microcontroller (150) retries the protocol detection sequence, enter a standby or error state, or alert the user (500).

[0227] By attempting serial protocol detection (210) before wireless protocol detection (220), the device (100) prioritises wired communication where available, which usually provides more reliable and lower-latency communication with the controller (700).

[0228] The device (100) is configured to re-execute the protocol detection sequence (200) upon detecting a loss of communication with the controller. This enables the device (100) to automatically reconfigure itself if it is moved to a different motorised bed or if the controller configuration changes.

[0229] Referring back to Figure 1 , the microcontroller (150) is programmed to receive a control command from the voice command device (800) and translate the control command into a control instruction compatible with the protocol determined by the protocol detection sequence (200).

[0230] Control commands received from the voice command device (800) are in the form of semantic intents representing desired bed movements or positions. Examples of semantic intents include "head up", "head down", "foot up", "foot down", "raise head", "lower head", "raise foot", "lower foot", "flat", "zero gravity", "lounge", "anti-snore", "TV position", "cardiac chair", "Trendelenburg", "reverse Trendelenburg", "height up", "height down", "memory position 1", "memory position 2", "stop", or similar commands.

[0231] The microcontroller (150) normalises received control commands into a set of controller-independent semantic codes. For example, variations such as "raise head", "head up", "lift the head", and "tilt the head up" are all normalised to a single semantic code such as "HEAD_UP".

[0232] The microcontroller (150) stores in the memory (158) a translation table mapping semantic codes to protocol-specific control instructions for one or more bed controller types.

[0233] The translation table includes, for each supported bed controller type, a mapping between each semantic code and a corresponding protocol-specific payload. For serial protocol controllers, the payload may include a sequence of bytes comprising, e.g., a start byte, a command byte, one or more parameter bytes, and a checksum or error detection byte. For wireless protocol controllers, the payload may include a characteristic handle and a value to be written to that characteristic, or an endpoint identifier and a command to be transmitted to that endpoint.

[0234] The translation table architecture enables a single interface device (100) to support multiple bed controller types without requiring hardware modifications. New bed controller types are supported by updating the translation table, such as, e.g., via a firmware update.

[0235] The translation table is stored in the non-volatile memory (158) of the microcontroller (150) and can be updated via a firmware update received over the wireless communicationsmodule (130).

[0236] The microcontroller (150) automatically selects an appropriate translation table entry based on the protocol type and controller identifier determined during the protocol detection sequence.

[0237] The microcontroller (150) identifies the specific bed controller type during the protocol detection sequence (200) by analysing response frames received from the controller (700), advertised service identifiers, manufacturer data, or other identifying information. The identified controller type is stored in the memory (158) and used to select the appropriate translation table entry for subsequent command translation.

[0238] The translation table also includes default or generic entries for controllers that are not specifically identified, enabling the device (100) to attempt communication with previously unknown controller types using common command formats.

[0239] The microcontroller (150) is programmed to receive status information from the controller (700) and transmit the status information to the voice command device (800) or a smart home platform.

[0240] The status information includes one or more of: a current position of the bed (900) (e.g., head elevation angle, foot elevation angle, bed height), a status of one or more actuators (e.g., moving, stationary, fault condition), a connection status with the controller (700), or other operational parameters.

[0241] The microcontroller (150) translates the received status information into a format compatible with the voice command device (800) or smart home platform. This enables the user (500) to query the current bed position via voice command (e.g., "What position is my bed in?") or view the bed status in a smart home application.

[0242] The microcontroller (150) is also programmed to implement one or more safety features to ensure safe operation of the motorised bed (900). For example, the microcontroller (150) implements a safety timeout that terminates actuator movement if an acknowledgment or response is not received from the controller (700) within a predetermined timeout period. The microcontroller (150) transmits a control instruction to the controller (700) and monitor for an acknowledgment. If no acknowledgment is received within a timeout period, such as, e.g., 1.5 to 2.0 seconds, the microcontroller (150) will automatically transmit a stop command to the controller (700) to terminate actuator movement.

[0243] Further, the microcontroller (150) implements command queuing to manage multiplecontrol commands received in succession. The command queue enforces serial execution of commands, such that only one actuator movement command is active at any given time.

[0244] The device (100) is configured to transmit a stop command to the controller (700) upon detecting a loss of communication with the voice command device (800) or the controller (700). This ensures that actuator movement is terminated if the communication link is interrupted.

[0245] The device (100) stores one or more safety parameters in the non-volatile memory (158), such as, e.g., timeout durations, maximum movement durations, or permitted command sequences. The safety parameters are configurable via a firmware update or a configuration interface.

[0246] The device (100) includes a voltage level shifting circuit for translating signal voltages between the microcontroller (150) and the serial port of the controller (700).

[0247] For example, the microcontroller (150) may operate at a first logic voltage level, such as, e.g., 3.3V, while the serial port of the controller (700) may operate at a second logic voltage level, such as, e.g., 5V. The voltage level shifting circuit enables bidirectional communication between the microcontroller (150) and the controller (700) notwithstanding the difference in logic voltage levels.

[0248] The voltage level shifting circuit is configured to support a range of controller logic voltages, such as, e.g., 3.3V, 5V, or 12V, enabling the device (100) to interface with controllers (700) operating at different voltage levels.

[0249] Figure 3 illustrates a method (300) for enabling communication between a voice command device and a controller of a motorised bed according to an embodiment of the present invention.

[0250] The method (300) can be carried out using the interface device (100) and the protocol detection sequence (200) as hereinbefore described.

[0251] Accordingly, and referring to Figures 1 and 2, the method (300) comprises the following steps:Step 310: connecting an interface device (100) to the bed (900), said interface device (100) including at least one connector (110) for connecting with a serial port of the controller (700), a wireless communications module (130) for wirelessly connecting to the controller (700) and the voice command device (800), and a microcontroller (150) operatively connected to the at least one connector (110) and the wireless communications module (130);Step 320: executing a protocol detection sequence (200) to automatically determine whether the controller (700) is configured to communicate via a serial protocol or a wireless protocol, said detection sequence (200) including transmitting one or more probe signals via the serial port, determining whether a valid response is received, and, if no valid response is received, initiating wireless scanning to discover the controller (700) by identifying devices advertising bed control services;Step 330: storing a result of the protocol detection sequence (200) in a memory (158) of the microcontroller (150);Step 340: receiving a control command from the voice command device (800), said control command corresponding to a voice command issued by a user (500) to the voice command device (800);Step 350: translating the control command into a control instruction compatible with the protocol determined by the protocol detection sequence (200); andStep 360: transmitting the control instruction to the controller (700) via the determined protocol to actuate a desired movement of the motorised bed (900).

[0252] In the present specification and claims (if any), the word ‘comprising’ and its derivatives including ‘comprises’ and ‘comprise’ include each of the stated integers but does not exclude the inclusion of one or more further integers.

[0253] Reference throughout this specification to ‘one embodiment’ or ‘an embodiment’ means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases ‘in one embodiment’ or ‘in an embodiment’ in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more combinations.

[0254] In compliance with the statute, the invention has been described in language more or less specific to structural or methodical features. It is to be understood that the invention is not limited to specific features shown or described since the means herein described comprises preferred forms of putting the invention into effect. The invention is, therefore, claimed in any of its forms or modifications within the proper scope of the appended claims (if any) appropriately interpreted by those skilled in the art.

Claims

CLAIMS1. An interface device for enabling communication between a voice command device and a controller of a motorised bed, said device configured for retrofit installation to the bed for enabling a user to control the bed through voice commands via the voice command device, said interface device including: at least one connector for connecting with a serial port of the controller; a wireless communications module for wirelessly connecting to the controller and the voice command device; a microcontroller operatively connected to the at least one connector and the wireless communications module, said microcontroller including at least one processor and a memory and programmed to: execute a protocol detection sequence to automatically determine whether the controller is configured to communicate via a serial protocol or via a wireless protocol, said detection sequence including transmitting one or more probe signals via the serial port, determining whether a valid response is received, and, if no valid response is received, initiating wireless scanning to discover the controller by identifying devices advertising bed control services; store a result of the protocol detection sequence in the memory; receive a control command from the voice command device, said control command corresponding to a voice command issued by a user to the voice command device; translate the control command into a control instruction compatible with the protocol determined by the protocol detection sequence; and transmit the control instruction to the controller via the determined protocol to actuate a desired movement of the motorised bed.

2. The interface device of claim 1 , wherein the controller of the motorised bed is configured to communicate via a serial port, or a wireless communication protocol.

3. The interface device of claim 1 or claim 2, wherein the interface device includes a body for at least partially housing the at least one connector, the at least one wireless communications module and the microcontroller.

4. The interface device of any one of claims 1 to 3, wherein the at least one connector includes at least one plug, the at least one plug being interchangeable with other plug types.

5. The interface device of claim 4, wherein the at least one plug and the device are connected together by a connecting mechanism or parts thereof.

6. The interface device of any one of claims 1 to 3, wherein the at least one connector includes a port for connecting to a serial port of the controller with a suitable cable.

7. The interface device of any one of claims 1 to 6, wherein the wireless communications module includes a cellular modem for connecting to a mobile telecommunications network, enabling the device to operate independently of a local wireless network.

8. The interface device of any one of claims 1 to 7, wherein the memory includes nonvolatile memory.

9. The interface device of any one of claims 1 to 8, wherein the device further includes one or more keys, buttons and / or switches for a user to control operation of the device.

10. The interface device of any one of claims 1 to 9, wherein the device includes at least one display for displaying information.

11. The interface device of any one of claims 1 to 10, wherein the device includes a power source for receiving electrical power for at least powering the microcontroller and the at least one wireless communications module.

12. The interface device of any one of claims 1 to 11 , wherein the device includes protection circuitry to protect the device from damage in the event of incorrect connection or a fault condition.

13. The interface device of any one of claims 1 to 12, wherein the protocol detection sequence includes a serial protocol detection phase followed by a wireless protocol detection phase.

14. The interface device of claim 13, wherein, in the serial protocol detection phase, the microcontroller transmits one or more probe signals via the at least one connector to the serial port of the controller, the probe signals including one or more probe frames configured to elicit a response from the controller if the controller is configured to communicate via a serial protocol.

15. The interface device of claim 14, wherein, in the serial protocol detection phase, if a valid response is received, the microcontroller determines that the controller is configured to communicate via a serial protocol and stores this result.

16. The interface device of any one of claims 13 to 15, wherein, in the wireless protocol detection phase, the microcontroller initiates wireless scanning via the wireless communications module to discover the controller, the wireless scanning including a Bluetooth Low Energy (BLE)scan, a Wi-Fi scan, a Zigbee, Z-Wave, or Thread scan.

17. The interface device of claim 16, wherein, if no suitable bed controller is discovered during the wireless protocol detection phase, the microcontroller retries the protocol detection sequence, enters a standby or error state, or alerts the user.

18. The interface device of any one of claims 1 to 17, wherein the microcontroller is programmed to receive status information from the controller and transmit status information to the voice command device or a smart home platform.

19. The interface device of any one of claims 1 to 18, wherein the microcontroller is programmed to implement one or more safety features to ensure safe operation of the motorised bed.

20. The interface device of any one of claims 1 to 19, wherein the microcontroller is further programmed to receive and apply over-the-air firmware updates via the wireless communications module.

21. The interface device of claim 1 , wherein the microcontroller is further programmed to communicate with a remote server via the wireless communications module to obtain translation data for translating control commands into control instructions compatible with the detected protocol.

22. The interface device of claim 1 , wherein the microcontroller is further programmed to transmit controller identification data to a remote server upon detecting a controller, and to receive and store translation data returned by the remote server.

23. The interface device of claim 1 , wherein the microcontroller is further programmed to transmit protocol detection data to a remote server, enabling a cumulative protocol library maintained by the remote server to be updated based on data from a plurality of deployed devices.

24. The interface device of claim 1 , wherein the microcontroller is further programmed to operate in a hybrid mode in which commonly-used translation data is stored locally in the memory and less common translation data is retrieved from a remote server as needed.

25. The interface device of claim 1 , wherein the device is accessible via a configuration interface provided by a web server, the web server being hosted by the microcontroller or by a remote server in communication with the device, the configuration interface enabling direct control of bed actuators via virtual controls.

26. The interface device of claim 1 , wherein the microcontroller is further programmed to store per-user calibration data specifying motor run times for each actuator function.

27. The interface device of claim 1 , wherein the microcontroller is further programmed to store one or more personalised positions, each personalised position specifying target positions for one or more actuators and being associated with a voice command label.

28. The interface device of claim 1 , wherein the microcontroller is further programmed to execute therapy-specific movement sequences comprising periodic position adjustments at configured intervals.

29. The interface device of claim 1 , wherein the microcontroller is further programmed to enforce configurable movement limits, the movement limits specifying maximum positions or restricted movements for one or more actuators.

30. The interface device of claim 1 , wherein the microcontroller is further programmed to maintain a diagnostic log recording operational events and errors, and to transmit log data to a remote server.

31. The interface device of claim 1 , wherein the microcontroller is further programmed to enable remote access by authorised personnel for remote configuration and troubleshooting.

32. A retrofit kit for providing voice control to an existing motorised bed, said kit including: an interface device of any one of claims 1 to 31 ; and a plurality of interchangeable plugs or cables adapted for connection to different serial port configurations of different motorised bed controllers.

33. A system for voice control of a motorised bed, said system including: an interface device of any one of claims 1 to 31 ; a controller of the motorised bed connected to the interface device via the serial port or communicating wirelessly with the wireless communications module; and a voice command device connected to the interface device via a network, wherein control commands corresponding to voice commands received at the voice command device are transmitted to the interface device, translated into protocol-specific control instructions, and delivered to the controller to actuate positioning functions of the motorised bed.

34. A system including: an interface device of any one of claims 1 to 31 ; and a remote server configured to receive controller identification data from the device and return protocol-specific translation data,wherein the remote server maintains a protocol library that is updated based on data received from a plurality of deployed devices.

35. A system including: a plurality of interface devices according to any one of claims 1 to 31 ; and a fleet management server configured to aggregate diagnostic data and manage firmware updates across the plurality of devices.

36. A method of enabling communication between a voice command device and a controller of a motorised bed, said method including: connecting an interface device to the bed, said interface device including at least one connector for connecting with a serial port of the controller, a wireless communications module for wirelessly connecting to the controller and the voice command device, and a microcontroller operatively connected to the at least one connector and the wireless communications module; executing a protocol detection sequence to automatically determine whether the controller is configured to communicate via a serial protocol or a wireless protocol, said detection sequence including transmitting one or more probe signals via the serial port, determining whether a valid response is received, and, if no valid response is received, initiating wireless scanning to discover the controller by identifying devices advertising bed control services; storing a result of the protocol detection sequence in a memory of the microcontroller; receiving a control command from the voice command device, said control command corresponding to a voice command issued by a user to the voice command device; translating the control command into a control instruction compatible with the protocol determined by the protocol detection sequence; and transmitting the control instruction to the controller via the determined protocol to actuate a desired movement of the motorised bed.

37. A method of operating an interface device for a motorised bed, the method including: detecting a controller of the motorised bed using a protocol detection sequence; transmitting controller identification data to a remote server; receiving translation data from the remote server; and using the translation data to translate control commands into control instructions compatible with the detected controller.

38. A method of updating a protocol library for motorised bed controllers, the method including: receiving, at a remote server, protocol detection data from a first interface device, the protocol detection data characterising a controller type detected by the first interface device;generating translation data for the detected controller type based on the received protocol detection data; storing the generated translation data in a protocol library; and distributing the generated translation data to a second interface device.

Images