Is it possible to trigger an alarm when there is no telemetry from the device for a specified time or for a given number of polling periods?
This trigger has the same meaning as a Dead man's switch for humans.
Or what is the best way for TB to detect a broken connection, assuming that not every IoT device can keep an open TCP/MQTT/etc session for a long time.
Thingsboard's builtin rules engine may help you on this, Official Docs
BTW, there is a nice user guide to help you detect inactive/offline devices, see here
Related
I am implementing automated HL7v2.7 reporting of observations on a point of care device. The way this works is by sending an "ORU^R30 Unsolicited Point-Of-Care Observation Message without Existing Order - Place an Order" message to what I'm assuming will be a laboratory information system or an associated channel in an integration engine. I'm currently going to have the device ask for IP/port numbers to the LIS and MPI/their associated connections on first set-up - our device is going to communicate over TCP/LLP.
Is this the smart way to do all this? I've never worked with HL7 or any kind of HIS before.
I appreciate any possible insight. This isn't the stuff you can learn about in the standard, and I don't think I can just email Epic and ask them how they design EHR/HIS systems.
Thanks!
Message Content: ORU^R30 is not a commonly used message type, but the structure is close enough to R01 that most systems will be able to receive it. Focus on making sure you collect as much patient demographics and the visit number, or better yet scan both from the patient's wristband barcode. You must have patient and visit to file the observations.
Transmission: It's safest to just do MLLP over TCP, it will speed up your installs because that's what everybody else does. The alternative is having the health system write something custom to receive the data, usually via the interface engine.
Network: It sounds like you're thinking of putting the connection info on the device. This probably is a bad idea, I would build some kind of aggregator service that actually sends data to the EHR, that way you don't have to deal with multiple devices trying to get through firewalls, etc.
I am writing a server for an iOS game. The game is turn-based and the only time the server needs to push information to the client is to notify of the opponent's move.
I am curious if anyone could comment on the performance and ease of implementation differences between using WebSockets and long polling. Also, if I used WebSockets, should I only use it to receive information and send POST requests for everything else, or should all communication be through the WebSocket?
Additionally, is there anything extra to consider between WebSockets and long polling if I am interested in also making a web client?
For anyone else who may be wondering, it could depends on how long typical interactions go between events?
Websocket: Anything more than a few tens of seconds, I don't think keeping a websocket open is particularly efficient (not to mention that IIRC it would disconnect anyway if the app loses focus)
Long polling: This forces a trade-off between server load (anything new now? how about now? ...) and speediness of knowing a change has occurred.
Push notifications: While this may be technically more complex to implement, it really would be the best solution IMO, since:
the notification can be sent (and delivered) almost immediately after an event occurs
there is no standby server load (either from open websockets, or "how about now?" queries) - which is especially important as your use-base grows
you can override what happens if a notification comes in while the user is in-app
should I only use it to receive information and send POST requests for
everything else
Yes, you should use WebSockets to fetch real-time updates only, and REST APIs to do BREAD stuff.
should all communication be through the WebSocket?
Short answer: No,
Check this article from PieSocket for more information about the best use cases for WebSockets. What Is WebSocket: Introduction And Usage
Does Blackberry API provide any methods to determine which one, GPS or Geolocation is better in current situation (according to signal level, network bandwidth and any other environment properties)?
There's many, many different algorithms you could use to determine which is the optimal location mode to use.
A well-tuned algorithm would have to account for things like
how fast does your user need a location fix?
how accurate does the fix need to be? is it just being used to find nearby movie theatres, or is the fix used for navigation (which needs to be really accurate)?
which mobile carrier are you on? GPS results may be independent of the carrier, but other geolocation technologies will depend on the carrier, and their infrastructure (assuming you're using the cellular network, and not Wi-Fi)
is there any reason to need to limit network transmissions (e.g. for a metered data plan, where you are frequently updating the location)?
how important is battery usage?
which BlackBerry OS versions are you targeting?
I'm sure I'm missing some other factors, but hopefully you can see that it's not a simple problem that can be solved without knowing something about your app and network deployment.
Also, this kind of algorithm for BlackBerry (Java) apps has traditionally taken a lot of work to optimize. As such, many developers (or clients) would consider this a closely-guarded business secret. So, it might be hard to find someone to publish their algorithm (but it doesn't hurt to ask, right?).
That said, you might at least take a look at the BlackBerry Simple Location API, which is an open source implementation of a basic algorithm that selects between GPS and Geolocation modes (if you allow it to use both). From the Javadocs (for the Optimal mode):
Operates in both Geolocation and GPS mode based on availability. First fix is computed in Geolocation mode, subsequent fixes in
Standalone mode. However if Standalone mode fails, falls back to Geolocation mode temporarily until a retry is attempted in
Standalone mode after a certain waiting period has passed. See setRetryFactor(int).
For single fix calls to getLocation(int), Geolocation mode is used first with a fallback to
Standalone mode if Geolocation mode fails.
I see you're in Belarus, but I don't know where your clients, or users are. If they're in the US, you may also need to consider something like Nav Builder Inside for geolocation if your app will support the Verizon network.
Anyway, I know this probably isn't the answer you wanted, but maybe it's a start?
I just read an article about WOL vs IPMI, it says "...used WOL to save millions of dollars by powering off idle desktops"(almost end at last paragraph but one), does it mean that WOL can be used to power off a desktop?
If so, how?
p.s. Does mainstream server support IPMI?
No, Wake On LAN lets you turn on PCs, not turn them off. The idea is that PCs need to be on in the middle of the night so they can get automatic updates; rather than leaving them on all day and all night just to get occassional updates, you can turn them off at the end of the day and use WOL to turn them on only when you need to update them.
I'm using the UPS service to monitor the state of my UPS from an application -- the key at HKLM\SYSTEM\CCS\Services\UPS\Status has all the information you can get from the Power control panel. BUT -- I'd like to be able to tell the UPS to shut down from my app as well. I know that the service can tell the UPS to shut down -- for instance, after running a set number of minutes on battery -- and I'm wondering if there's some kind of command I can send to the service to initiate a shutdown manually.
I'm having trouble searching for this information -- people tend to misspell "Uninterruptible" (hrm, Firefox red-lined that but doesn't have an alternative) and "UPS" just gets hits for the shipping service. Maybe I can do something through System.ServiceController, or WMI?
CLARIFICATION: Yes, I am talking about powering down the physical UPS device. I know how to stop the service. I figured it would be a common problem -- I want my UPS to turn off with the PC. I had an idea I'm going to try, based on this page. You see, APC (and everybody else) has to supply a DLL for the UPS service to call, and since the function calls are well documented, there's no reason I shouldn't be able to P/Invoke them. I'll re-edit this once I know whether or not it worked.
Update: I tried invoking UPSInit, then UPSTurnOff, and nothing happens. I'll tinker with it some more, but the direct call to apcups.dll might be a dead end.
Check my comments to Herman, you want to shut the UPS down, not the UPS SERVICE, correct? I mean, you want that thing to shut off, kill the power, etc, right?
If so, you are looking it on a UPS by UPS model. I doubt two of them would work the same.
In your searches, instead of UPS, try "APC", or "battery". I think a lot of the code is what runs on laptops to deal with being on battery, etc...
Some place hidden in some dusty old files I have protocol information for APC UPS's, and the commands they respond to, and what they send to the PC etc. But this was WAY back in the day when we used to connect our UPS's to our computers with SERIAL cables... You could actually talk to a UPS with Qmodem or Hyperterm...
Learned it from talking to the guys at APC. They are very nice, and helpful. Now-a-days, I think you just post a URL coming from your Powerchute software, and it will talk directly to the UPS, and carry out your commands.
OK, I have the answer (tested!), but it's not pretty. My APC UPS communicates using the APC "Smart" protocol (more here). What you need in my case is a "soft shutdown", "S" command. But first you need to make sure it's in "Smart" mode ("Y"). Now, if you want to let the Windows UPS service monitor state, the service will have an iron grip on the COM port. So you can either a) let the Windows service turn the UPS off, or b) kill the service and turn the UPS off yourself.
The UPS itself has a "grace period" after it gets the "S" command, giving you time to shut down your OS. This means that to do (a) above, you have to:
Kill utility (mains) power
Wait for the Windows UPS Service timeout (default and minimum 2 minutes)
Wait for Windows to shut down -- right near the end, it will send the "S" command
Wait for the UPS grace period, after which it will actually turn itself off
I think we're going to opt for (a), just because (b) involves extra work killing the service and implementing the serial comms.
Please, tell in what language are you trying to do that... if you're using .NET you can do that with ServiceController class (read the docs).
For controlling services in Win32 API using C/C++, Service Functions (Windows).
For example to stop a service you can use ControlService function as follows (this is a quick and dirty example):
OpenService (hServMgr, TEXT("\\UPS_SERVICE_0"), SC_MANAGER_ALL_ACCESS);
SERVICE_STATUS stat;
ControlService (hUpsService, SERVICE_CONTROL_STOP, &stat)
Note that you need to provide a Service Manager handle in hServMgr and the \\UPS_SERVICE_0 name is the name that must match with your desired UPS service (either the Windows built-in or another).
Remember that to stop a service you need the proper security rights. This is not a problem with an Adminstration account, but keep in mind what happens when logging with a non-admin account.
Hope that helps.
About shutting down the physical UPS device, I remember back in WIn98 days I was able to poweroff the device talking with the UPS through the COM port, altough I don't remember the brand or how the programming interface was.