Shared equipment control method and device, equipment and medium

Abstract

The invention belongs to the technical field of electric appliances, and particularly relates to a control method and device of shared equipment, equipment and a medium, and the method comprises the steps: obtaining a use request of a user side; sending a report state instruction to the target device according to the use request; if the target device responds to the report state instruction, payment information is sent to the user side, and the payment information is used for indicating the amount to be paid by the user when the target program is operated; and after the user side completes payment according to the payment information, issuing a starting instruction to the target equipment. And if the target device does not normally start the target program, executing a corresponding restart strategy according to the historical state information of the target device. According to the method, the online information of the equipment can be actively inquired, the current state of the equipment can be confirmed, and the corresponding restart strategy is performed according to the historical state information, so that the hysteresis of the cloud for sensing the state of the equipment is avoided, the success rate of the restart operation is increased, and the user experience is enhanced.

Description

Technical Field

[0001] This application belongs to the technical field of electrical appliances, and particularly relates to a control method, device, equipment and medium for shared devices. Background Art

[0002] For shared devices, such as shared washing machines, usually the corresponding operation program of the device needs to be started after the user makes a payment. The user's payment and control of the shared device both need to go through the cloud, that is, the user pays through the cloud and starts the device program through the cloud. And the shared device communicates with the cloud through the network, and reports the status information by sending a data packet carrying heartbeat data to the cloud. Usually, when the cloud does not receive several consecutive heartbeat packets, the shared device is considered offline.

[0003] However, the above method makes the cloud have a lag in obtaining the offline information of the shared device, and it is easy to occur that the shared device is actually offline when the user makes a payment, because the cloud has not obtained the offline information of the device in time due to the lag. At the same time, if the network module of the shared device finds that it cannot communicate with the cloud or the network is unstable, it generally performs a restart operation, but at this time the cloud shows that the shared device is normally online. The above problems will all lead to the situation that the device may not start normally after the user makes a payment, affecting the user experience. Summary of the Invention

[0004] To solve the above problems, this application provides a control method, device, equipment and medium for shared devices.

[0005] In a first aspect, this application provides a control method for a shared device, the method includes:

[0006] Obtain a usage request from the user terminal, the usage request is used to indicate a target device to start a target program;

[0007] According to the usage request, send a reporting status instruction to the target device, the reporting status instruction is used to indicate the target device to report the current online information;

[0008] If the target device responds to the reporting status instruction, send payment information to the user terminal, the payment information is used to indicate the amount that the user needs to pay to run the target program;

[0009] When the user terminal completes the payment according to the payment information, send a start instruction to the target device to enable the target device to start the target program.

[0010] In a possible implementation manner, after sending the start instruction to the target device, it further includes:

[0011] If the target device fails to start the target program normally, execute the corresponding restart policy according to the historical status information of the target device.

[0012] In a possible implementation, the executing the corresponding restart policy according to the historical status information of the target device includes:

[0013] According to the historical status information, obtain the success rate of heartbeat information reporting within a preset period closest to the current time for the target device, where the target device reports heartbeat information at a first preset time interval to indicate that the target device is normally online;

[0014] If the reporting success rate is greater than a first preset threshold, execute a first restart policy;

[0015] If the reporting success rate is less than or equal to the first preset threshold, execute a second restart policy;

[0016] Wherein, when executing the first restart policy or the second restart policy, the network module of the target device is reset at a second preset time interval until the target device can respond to the current start instruction.

[0017] In a possible implementation, the executing the first restart policy includes:

[0018] Repeatedly send a start instruction to the target device at a first time interval;

[0019] Determine whether the target device responds to the start instruction within a first preset number of sending times;

[0020] If so, send a first prompt message to the client to prompt the user that the target program has started successfully;

[0021] If not, return the paid amount to the client according to the payment information.

[0022] In a possible implementation, the executing the second restart policy includes:

[0023] Repeatedly send a start instruction to the target device at a second time interval and determine whether the target device responds to the start instruction within a second preset number of sending times, where the first time interval is less than the second time interval and the first preset number of sending times is greater than the second preset number of sending times;

[0024] If so, send a first prompt message to the client to prompt the user that the target program has started successfully; if not, return the paid amount to the client according to the payment information.

[0025] In one possible implementation, the method further includes:

[0026] Obtain the historical restart success rate of the target device according to the historical status information;

[0027] Determine whether the historical restart success rate is greater than a second preset threshold;

[0028] If so, execute the first restart policy;

[0029] If not, execute the second restart policy.

[0030] In one possible implementation, the method further includes:

[0031] If the target device does not respond to the reported status instruction, obtain alternative device information, where the alternative device information is used to indicate other shared devices available for display;

[0032] Push a second prompt message to the user terminal to prompt the user that the target device is unavailable, and push the alternative device information to the user terminal for the user to select.

[0033] In a second aspect, the present application provides a control device for a shared device, and the device includes:

[0034] An acquisition module, configured to acquire a usage request from a user terminal, where the usage request is used to indicate a target device to start a target program;

[0035] A sending module, configured to send a reported status instruction to the target device according to the usage request, where the reported status instruction is used to instruct the target device to report current online information;

[0036] The sending module is further configured to, if the target device responds to the reported status instruction, send payment information to the user terminal, where the payment information is used to indicate the amount that the user needs to pay to run the target program;

[0037] A processing module, configured to, after the user terminal completes payment according to the payment information, send a start instruction to the target device to enable the target device to start the target program.

[0038] In a third aspect, the present application provides a computer-readable storage medium, in which computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, they are used to implement the method according to any item in the first aspect.

[0039] In a fourth aspect, the present application provides a shared device, including: at least one processor and a memory; wherein,

[0040] The memory stores computer-executable instructions;

[0041] The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the method according to any one of the first aspect.

[0042] The control method, device, equipment and medium of the shared device provided in this embodiment obtain the usage request of the user terminal, send a reporting status instruction to the target device, so that the target device reports the current online information. If the target device responds to the reporting status instruction, payment information is sent to the user terminal to enable the user to pay the corresponding amount. After the user completes the payment, a start instruction is sent to the target device. Further, if the target device fails to normally start the target program, a corresponding restart policy is executed according to the historical status information of the target device. This method can actively query the device online information, confirm the current status of the device, and at the same time execute the corresponding restart policy according to the historical status information, avoiding the lag of the cloud's perception of the device status, increasing the success rate of the restart operation, and enhancing the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] The drawings here are incorporated into the specification and form a part of this specification, showing the embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0044] Figure 1 is the flow of the control method of the shared device provided by the embodiment of the present application Figure 1 ;

[0045] Figure 2 is the flow of the control method of the shared device provided by the embodiment of the present application Figure 2 ;

[0046] Figure 3 is the flow of the control method of the shared device provided by the embodiment of the present application Figure 3 ;

[0047] Figure 4 is the control device diagram of a shared device provided by the embodiment of the present invention;

[0048] Figure 5 is the hardware schematic diagram of the shared device provided by the embodiment of the present invention.

[0049] Through the above drawings, the clear embodiments of the present application have been shown, and there will be more detailed descriptions later. These drawings and text descriptions are not intended to limit the scope of the concept of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following will clearly and completely describe the technical solutions in this application in conjunction with the accompanying drawings in this application. Apparently, the described embodiments are some, but not all, of the embodiments of this application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in this application without creative efforts shall fall within the scope of protection of this application.

[0051] In the description and claims of this invention and the above accompanying drawings, the terms "first", "second", "third", "fourth", etc. (if any) are used to distinguish similar objects and do not necessarily have to be used to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances so that the embodiments of this invention described herein can be implemented, for example, in an order different from those illustrated or described herein.

[0052] In the embodiments of this application, words such as "exemplary" or "for example" are used to represent examples, illustrations, or explanations. Any embodiment or design solution described as "exemplary" or "for example" in this application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of words such as "exemplary" or "for example" is intended to present relevant concepts in a specific manner.

[0053] Currently, between a typical Internet of Things cloud platform (cloud) and shared devices, they usually detect liveness through heartbeats. For convenience of description, the following will refer to shared devices as devices. Specifically, the device sends a data packet carrying heartbeat data to the cloud at fixed time intervals. After receiving it, the cloud sends a received packet back to the device. The whole process is that the device actively reports to the cloud to indicate its own survival status. When the cloud does not receive N consecutive (N>1) heartbeat packets, the device is considered offline. Therefore, the cloud generally has a lag in detecting that the device is offline, usually detecting it 2 - 3 minutes after the device actually goes offline at the device side.

[0054] When the network module at the device side finds that the heartbeat packet or communication message cannot be sent, or due to other reasons such as unstable network, it generally restarts the module and reconnects to the base station, which takes about 10 - 20 seconds. During this period, the offline mechanism of the cloud will not be triggered, and the device still shows online in the cloud. Therefore, there may be misjudgments in determining the online status of the device through heartbeats, especially when the network is poor, resulting in the device frequently going online and offline, and when the device is actually offline but the cloud has not yet sensed the "false online" situation. When the cloud misjudges that the device is online, it allows users to make payments, but at this time, the user cannot normally start the device, affecting the user experience.

[0055] Based on the above problems, the present application proposes a control method for shared devices. By obtaining the usage request from the user terminal, it sends a reporting status instruction to the target device, so that the target device reports its current online information. If the target device responds to the reporting status instruction, it sends payment information to the user terminal to enable the user to pay the corresponding amount. After the user completes the payment, it sends a start instruction to the target device. If the target device fails to normally start the target program, it executes the corresponding restart strategy according to the historical status information of the target device. Specifically, it determines the size of the reporting success rate of the heartbeat information or the historical restart success rate of the target device in the near future according to the historical status information. If it reaches the threshold, it means that the current restart operation success rate of the target device is relatively high, and it tries to enable the device by appropriately increasing the number of retries. This method actively queries the device online information to confirm the current online status of the device, which has timeliness. Even if the device may go offline immediately after the user makes a payment and cannot be started, it can also adjust the restart operation by judging the historical status information of the device. Under the condition of ensuring the reasonable use of cloud resources, it increases the success rate of the restart operation so that the device can be used normally. The cloud's perception of the device status is no longer lagging, enhancing the user experience.

[0056] The following uses specific embodiments to detail the technical solution of the present application and how the technical solution of the present application solves the above technical problems. These specific embodiments below can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The following will describe the embodiments of the present application with reference to the drawings.

[0057] Figure 1 is the flow of the control method for shared devices provided by the embodiments of the present application Figure 1 As Figure 1 shown, the method includes:

[0058] S101. Obtain the usage request from the user terminal, where the usage request is used to instruct the target device to start the target program.

[0059] In this step, the user sends a usage request to the cloud through the user terminal, which is used to instruct the target device to start the target program. For example, when the user needs to use a shared washing and care device, the user can select the device and the washing and care program to run through the application, and after clicking to confirm, a usage request is generated and sent to the cloud. The target device to be used can be confirmed by scanning the QR code on the device body, selecting through the user interface or other means, so as to actively inquire about the status information of the target device subsequently.

[0060] S102. According to the usage request, send a reporting status instruction to the target device, where the reporting status instruction is used to instruct the target device to report its current online information.

[0061] In this step, once a usage request from the user is received, a reporting status instruction is sent to the target device according to the request, so that the target device reports its current online information, such as whether the device is available, the device status, etc. By obtaining the online information of the target device, it can be further determined whether the device can meet the user's request.

[0062] S103. If the target device responds to the reporting status instruction, payment information is sent to the user terminal, and the payment information is used to indicate the amount that the user needs to pay to run the target program.

[0063] In this step, if the target device successfully responds to the reporting status instruction, that is, the target device successfully reports its current online information, payment information is sent to the user terminal. The payment information informs the user of the amount required to run the target program, and the user can decide whether to pay the corresponding amount to use the program on the target device according to the payment information.

[0064] Exemplarily, if the target device does not respond to the reporting status instruction, alternative device information is obtained, and the alternative device information is used to indicate other shared devices that are shown as available;

[0065] A second prompt message is pushed to the user terminal to prompt the user that the target device is unavailable, and the alternative device information is pushed to the user terminal for the user to select.

[0066] It should be noted that when the target device does not respond to the reporting status instruction, it means that the target device is unavailable. At this time, the information of alternative devices can be obtained, and this information indicates other available shared devices. At the same time, a second prompt message is sent to the user terminal to inform the user that the target device is unavailable and provide the alternative device information for the user to select. The user can select another device from the list of alternative devices to start the target program. Exemplarily, the available device closest to the target device or other available devices within a preset range can be preferentially recommended to the user for the convenience of replacement.

[0067] S104. After the user terminal completes the payment according to the payment information, a start instruction is sent to the target device to enable the target device to start the target program.

[0068] In this step, when the user completes the payment, a start instruction is sent to the target device to start the target program. After sending the start instruction, it can be determined whether the target program is successfully started by confirming whether the target device returns information indicating successful startup.

[0069] Exemplarily, if the target device fails to normally start the target program, a corresponding restart strategy is executed according to the historical status information of the target device.

[0070] It should be noted that if the target device fails to start the target program normally, it means that the target device may go offline immediately after the user makes a payment. At this time, the start device can be retried. The retry process can be that the cloud sends a start instruction to the target device again. If it still fails to start normally, the instruction can be sent repeatedly. At this time, when the target device detects that its own network is disconnected, for example, when it finds that the heartbeat packet or communication information cannot be sent, it will trigger a restart of its own network module. The cloud consumes resources when sending instructions or communicating with the device. Therefore, in order to avoid the cloud repeatedly sending start instructions to the device, which may cause excessive consumption of cloud resources, and occupying unnecessary resources for devices that are already in a stable offline state, the devices with a relatively high restart success rate can be identified based on the historical status information of the target device and the retry times can be increased, while other devices adopt a strategy with fewer retry times. Through a reasonable restart strategy, the cloud resources can be moderately allocated to identify in a timely manner the devices that can be restored online in the short term.

[0071] The control method for the shared device provided in this embodiment obtains the usage request from the user side and sends a reporting status instruction to the target device so that the target device reports the current online information. If the target device responds to the reporting status instruction, it sends payment information to the user side to enable the user to pay the corresponding amount. After the user completes the payment, a start instruction is sent to the target device. Further, if the target device fails to start the target program normally, a corresponding restart strategy is executed according to the historical status information of the target device. This method can actively query the device online information, confirm the current status of the device, and at the same time perform the corresponding restart strategy according to the historical status information, avoiding the lag of the cloud's perception of the device status, increasing the success rate of the restart operation, and enhancing the user experience.

[0072] Figure 2 It is the flow of the control method for the shared device provided in the embodiment of the present application Figure 2 As Figure 2 shown, on the basis of the Figure 1 embodiment, the process of executing the restart strategy is described in detail. The method includes:

[0073] S201. According to the historical status information, obtain the success rate of heartbeat information reporting of the target device within a preset period closest to the current time.

[0074] Among them, the target device reports heartbeat information at a first preset time interval to indicate that the target device is normally online.

[0075] In this step, the target device reports heartbeat information at a first preset time interval, which is equivalent to a rule pre-agreed with the cloud. Therefore, the success rate of heartbeat information reporting within the nearest preset period from the current time of the target device can be obtained to determine the actual situation of the device reporting based on the rule within the nearest preset period, and it is used to measure the most recent online status of the device. The success rate of heartbeat information reporting represents the success rate of the device sending heartbeats or maintaining connections.

[0076] Based on the above content, considering the situation that the network module may experience multiple anomalies in a short period of time but then recover, the success rate of the device's heartbeat information reporting becomes important. Through the recent success rate of heartbeat information reporting, the network stability trend of the network environment where the device is located can be determined. When the reporting success rate is greater than a threshold, such as 95%, it indicates that the device's network may have experienced short-term offline but recovered. By identifying such situations, it is possible to avoid prematurely marking the current target device as offline and further execute the corresponding restart strategy.

[0077] S202. If the reporting success rate is greater than the first preset threshold, then execute the first restart strategy.

[0078] S203. Repeat sending the start instruction to the target device at a first time interval.

[0079] S204. Determine whether the target device responds to the start instruction within the first preset number of transmissions.

[0080] S205. If so, send a first prompt message to the client to prompt the user that the target program has started successfully.

[0081] S206. If not, then return the paid amount to the client according to the payment information.

[0082] It should be noted that when the reporting success rate is greater than the first preset threshold, it indicates that the current target device may have resumed online in the short term. At this time, the start instruction can be repeatedly sent to the target device at a relatively small first time interval to ensure that the start program can be triggered in a timely manner when the target device resumes networking. It should be understood that at this time, the target device triggers its own network module to restart due to being offline, and the single restart process of the network module will consume some time. Therefore, the network module is reset at a certain period until the target device can receive messages or instructions from the cloud.

[0083] The cloud can set a maximum upper limit for the number of retry attempts, that is, the first preset number of sending attempts. After exceeding this number, the start command will no longer be sent, which can prevent the device from being in a continuous attempt-to-start state. Moreover, the total time for restarting the first preset number of times at the first preset time interval can correspond to the time length for triggering the device offline mechanism. When this time length is reached, it is considered that the target device is in a stable offline state. At this time, the cloud shows that the target device is offline, so as to proceed with the subsequent processing process for the offline device.

[0084] S207. If the reported success rate is less than or equal to the first preset threshold, then execute the second restart strategy.

[0085] S208. Repeat sending the start command to the target device at the second time interval;

[0086] S209. Determine whether the target device responds to the start command within the second preset number of sending attempts.

[0087] Among them, the first time interval is less than the second time interval, and the first preset number of sending attempts is greater than the second preset number of sending attempts.

[0088] S2010. If so, execute S205.

[0089] S2011. If not, execute S206.

[0090] It should be noted that when the reported success rate is less than or equal to the first preset threshold, it means that the current device may not have the network conditions to resume online in the short term. At this time, the start command can be repeatedly sent to the target device at a larger second time interval to ensure that it can be recognized that the target device may still resume online even when it does not have the conditions for short-term online.

[0091] Correspondingly, at this time, the maximum upper limit of the number of retry attempts is a value smaller than the first preset number of sending attempts, that is, the second preset number of sending attempts. This differential restart strategy can enable the cloud to appropriately increase or decrease resource allocation for different situations, avoid excessive waste of resources, and at the same time prevent excessive unnecessary retries from burdening the cloud. Correspondingly, the device can also pre-configure the maximum number of resets of the network module. The time corresponding to the maximum number of resets can include the total time corresponding to the first preset number or the second preset number to ensure that the network module of the device stops resetting after the cloud retry operation is completed.

[0092] Optionally, each time a retry is performed, the user can receive corresponding feedback indicating whether the current retry is successful. If the retry is successful, the user can learn that the device has been started. If the maximum number of retries is reached without success, a notification of non-startup is sent to the user, and the paid amount is returned to the user. Exemplarily, after returning the amount, other available devices can be further recommended to the user.

[0093] The control method for the shared device provided in this embodiment obtains the reporting success rate of the recent heartbeat information in the historical status information. If the reporting success rate is greater than the first preset threshold, the start instruction is repeatedly sent to the target device at a shorter time interval and with a larger retry upper limit; if the reporting success rate is less than or equal to the first preset threshold, the start instruction is repeatedly sent to the target device at a longer time interval and with a smaller retry upper limit. This method can adjust the restart operation by judging the historical status information of the device to ensure the reasonable use of cloud resources, increase the success rate of the restart operation, enable the device to be used normally, and improve the operating efficiency of the system.

[0094] Figure 3 It is the flow of the control method for the shared device provided in the embodiment of the present application Figure 3 As Figure 3 shown, on the basis of the Figure 2 embodiment, the process of executing the restart policy is further described in detail. The method includes:

[0095] S301. Obtain the historical restart success rate of the target device according to the historical status information.

[0096] S302. Judge whether the historical restart success rate is greater than the second preset threshold.

[0097] S303. If so, execute the first restart policy.

[0098] S304. If not, execute the second restart policy.

[0099] It should be noted that the principle of restarting based on the historical restart success rate is the same as that of restarting based on the reported success rate. The corresponding first restart policy and second restart policy have been described in the above embodiments. When the historical restart success rate is greater than the second preset threshold, it indicates that the target device may have the network conditions or other conditions for short-term online, and the probability of successful restart currently is relatively high. At this time, the number of retries can be appropriately increased; when the historical restart success rate is less than or equal to the second preset threshold, it indicates that the restart success rate of the current target device may be relatively small. At this time, the number of retries can be appropriately reduced. Based on this, the effect of reasonably using cloud resources can also be achieved. Exemplarily, all historical restart data recorded for the target device up to the current time can be selected, or the recent restart data of the target device can be selected, and the historical restart success rate can be obtained according to the restart data, which is not limited here.

[0100] Optionally, for the reported success rate and the historical restart success rate, either one of them can be selected as the basis for adjusting the restart policy, or both of them can be combined and used as the basis for adjusting the restart policy at the same time, which is not limited here.

[0101] Exemplarily, when executing the first restart policy or the second restart policy, the network module of the target device is reset at a second preset time interval until the target device can respond to the current start instruction.

[0102] That is, in any of the above embodiments, when executing the first restart policy or the second restart policy, the network module of the target device is reset at a second preset time interval, and this function can be achieved by pre-configuring the target device. And the restart of the network module needs to continue until the target device can respond to the current start instruction. Optionally, the setting of the upper limit time or number of times of network module restart is satisfied after the cloud ends the repeated issuance of start instructions.

[0103] The control method of the shared device provided in this embodiment adjusts the restart policy of the target device dynamically by obtaining the historical restart success rate in the historical status information. This method provides another aspect of reference to ensure the reasonable use of cloud resources and improve the operation efficiency of the system.

[0104] Figure 4 This is a control device diagram of a shared device provided by an embodiment of the present invention. As Figure 4 shown, the control device 40 includes: an acquisition module 401, a sending module 402, and a processing module 403.

[0105] The acquisition module 401 is used to acquire the usage request of the user terminal, and the usage request is used to instruct the target device to start the target program;

[0106] A sending module 402, configured to send a reporting status instruction to the target device according to the usage request, where the reporting status instruction is used to instruct the target device to report current online information;

[0107] The sending module 402 is further configured to, if the target device responds to the reporting status instruction, send payment information to the user terminal, where the payment information is used to indicate the amount that the user needs to pay to run the target program;

[0108] A processing module 403, configured to send a start instruction to the target device after the user terminal completes payment according to the payment information, so that the target device starts the target program.

[0109] Figure 5 This is a hardware schematic diagram of the shared device provided by the embodiment of the present invention. As Figure 5 shown, the shared device 50 provided in this embodiment includes: at least one processor 501 and a memory 502. The device 50 further includes a communication component 503. Among them, the processor 501, the memory 502, and the communication component 503 are connected through a bus 504.

[0110] In a specific implementation process, at least one processor 501 executes the computer execution instructions stored in the memory 502, so that at least one processor 501 executes the above method.

[0111] For the specific implementation process of the processor 501, reference can be made to the above method embodiment, and its implementation principle and technical effects are similar, which will not be elaborated here in this embodiment.

[0112] In the above Figure 5 shown embodiment, it should be understood that the processor may be a central processing unit (English: Central Processing Unit, abbreviated: CPU), and may also be other general-purpose processors, digital signal processors (English: Digital Signal Processor, abbreviated: DSP), application specific integrated circuits (English: Application Specific Integrated Circuit, abbreviated: ASIC), etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in combination with the invention can be directly embodied as being executed by a hardware processor, or executed by a combination of hardware and software modules in the processor.

[0113] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (Non-volatile Memory, NVM), such as at least one disk memory.

[0114] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of convenience in representation, the buses in the accompanying drawings of this application are not limited to only one bus or one type of bus.

[0115] This application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When the processor executes the computer-executable instructions, the method described above is implemented.

[0116] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, a magnetic disk or an optical disc. The readable storage medium can be any available medium accessible by a general-purpose or special-purpose computer.

[0117] An exemplary readable storage medium is coupled to the processor, so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an Application Specific Integrated Circuits (ASIC). Of course, the processor and the readable storage medium can also exist as discrete components in a device.

[0118] The division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection to each other can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be in an electrical, mechanical or other forms.

[0119] The unit described as a separation component may or may not be physically separated. The component shown as a unit may or may not be a physical unit, that is, it may be located in one place or distributed across multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0120] In addition, in each embodiment of the present invention, each functional unit can be integrated into a processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit.

[0121] If the above functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical discs that can store program codes.

[0122] Those of ordinary skill in the art can understand that all or part of the steps of implementing the above method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When this program is executed, it executes the steps of the above method embodiments; and the aforementioned storage medium includes: various media such as ROMs, RAMs, magnetic disks, or optical discs that can store program codes.

[0123] So far, the technical solution of this application has been described in conjunction with the preferred embodiments shown in the accompanying drawings. However, it is easy for those skilled in the art to understand that the protection scope of this application is obviously not limited to these specific embodiments. The above embodiments are only used to illustrate the technical solution of this application, rather than to limit it; although this application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some or all of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A control method for a shared device, characterized in that, The method includes: Obtaining a usage request of a client, where the usage request is used to instruct a target device to start a target program; According to the usage request, sending a reporting status instruction to the target device, where the reporting status instruction is used to instruct the target device to report current online information; If the target device responds to the reporting status instruction, sending payment information to the client, where the payment information is used to indicate the amount that the user needs to pay to run the target program; After the client completes the payment according to the payment information, sending a start instruction to the target device so that the target device starts the target program.

2. The method according to claim 1, wherein After sending the start instruction to the target device, it further includes: If the target device fails to start the target program normally, executing a corresponding restart policy according to the historical status information of the target device.

3. The method according to claim 2, wherein The executing the corresponding restart policy according to the historical status information of the target device includes: According to the historical status information, obtaining the reporting success rate of heartbeat information within a preset period closest to the current time of the target device, where the target device reports heartbeat information at a first preset time interval to indicate that the target device is normally online; If the reporting success rate is greater than a first preset threshold, executing a first restart policy; If the reporting success rate is less than or equal to the first preset threshold, executing a second restart policy; Wherein, when executing the first restart policy or the second restart policy, the network module of the target device is reset at a second preset time interval until the target device can respond to the current start instruction.

4. The method according to claim 3, wherein The executing the first restart policy includes: Repeatedly sending a start instruction to the target device at a first time interval; Judging whether the target device responds to the start instruction within a first preset number of sending times; If so, sending a first prompt message to the client to prompt the user that the target program has started successfully; If not, returning the paid amount to the client according to the payment information.

5. The method according to claim 4, wherein The executing the second restart policy includes: Repeatedly sending a start instruction to the target device at a second time interval; and judging whether the target device responds to the start instruction within a second preset number of sending times, where the first time interval is less than the second time interval, and the first preset number of sending times is greater than the second preset number of sending times; If so, sending a first prompt message to the client to prompt the user that the target program has started successfully; if not, returning the paid amount to the client according to the payment information.

6. The method according to claim 3, characterized in that, The method further includes: According to the historical status information, obtaining the historical restart success rate of the target device; Judging whether the historical restart success rate is greater than a second preset threshold; If so, executing the first restart policy; If not, executing the second restart policy.

7. The method according to claim 1, characterized in that, The method further includes: If the target device fails to respond to the reporting status instruction, obtaining alternative device information, where the alternative device information is used to indicate other available shared devices; Push a second prompt message to the client to prompt the user that the target device is unavailable, and push the alternative device information to the client for the user to select.

8. A control device for a shared device, characterized in that, The device includes: An acquisition module, configured to acquire a usage request of a client, where the usage request is used to instruct a target device to start a target program; A sending module, configured to send a reporting status instruction to the target device according to the usage request, where the reporting status instruction is used to instruct the target device to report current online information; The sending module is further configured to, if the target device responds to the reporting status instruction, send payment information to the client, where the payment information is used to indicate the amount that the user needs to pay to run the target program; A processing module, configured to send a start instruction to the target device after the client completes payment according to the payment information, so that the target device starts the target program.

9. A computer-readable storage medium, characterized in that, Computer-executable instructions are stored in the computer-readable storage medium, and when the computer-executable instructions are executed by a processor, they are used to implement the method according to any one of claims 1-7.

10. A shared device, characterized in that, It includes: At least one processor and a memory; wherein, The memory stores computer-executable instructions; The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the method according to any one of claims 1-7.

Images