Readings reach Logable over MQTT or HTTPS. Modbus registers and PLC tags arrive through a gateway on your own network.
Three ways a reading gets in. Two of them are direct, and the third puts a gateway on your own network between the equipment and Logable.
A device or a gateway publishes to its own topic over TLS, with its own token. One outbound connection, and no inbound port.
One POST per reading to the device endpoint, with a device token. No broker to run.
A gateway reads the registers on your own network and publishes them upward as MQTT.
These reach Logable directly. Nothing sits in between, and nothing has to be installed on your network.
MQTT over TLS
A device or a gateway publishes to its own topic with its own token. One outbound connection, and no inbound port to open. Send readings over MQTT.
HTTPS device ingest
One POST per reading to the device endpoint, with a device token. Anything that can make an HTTPS request can send a reading. Send readings over HTTPS.
HTTPS stream ingest
Anything with a number and a time can be sent to a stream, and gets the same charts and the same alerts as a device. Send data to a stream.
Outgoing webhooks
Logable posts an alert or an event to an endpoint you own, signed, so another system can act on it. Send alerts to a webhook.
A gateway on your own network reads the equipment and publishes to Logable over MQTT. Logable never speaks these protocols itself, and nothing is written back to the equipment.
Modbus RTU
Serial devices on RS-485 are read by a gateway, which publishes each register upward. Connect a PLC or a Modbus device.
Modbus TCP
Read by a gateway on the plant network, and published upward over MQTT on the schedule you set. Connect a PLC or a Modbus device.
PLC tags
A gateway polls the PLC on its own schedule and publishes the tags. The control system keeps control, and nothing is written back. Connect a PLC or a Modbus device.
Stated plainly, so the answer takes one line rather than a call. Where there is something to do instead, the line says what it is.
LoRaWAN
Logable decodes no LoRaWAN payloads. A LoRaWAN network server can post decoded readings to the HTTPS endpoint, which works and leaves the network server in the path as a second system to run.
SMS and WhatsApp as alert channels
Alerts reach email, push notifications on the mobile app, the in-app inbox and outgoing webhooks. There is no SMS channel and no WhatsApp channel.
Modbus straight into Logable
There is no Modbus client inside Logable. A gateway on your own network is the path, and it is documented.
A read API for your own application
Logable documents the way readings come in and the way events go out. There is no documented read API for building an application on top.
Five pages, each with a table that carries the date it was checked and the rows where the other option wins.
A hosted LoRaWAN platform, row by row against Logable.
Learn moreAn open platform you host yourself, row by row.
Learn moreA platform with SMS and voice alerts, row by row.
Learn moreA clipboard and a spreadsheet, and where they are enough.
Learn moreA dialler with one set point, and where it is enough.
Learn moreNot directly. A gateway on your own network reads the Modbus registers and publishes them to Logable over MQTT. That is the documented path, and the gateway guide covers it end to end. Nothing is written back to the equipment.
No. The gateway makes one outbound connection, over MQTT with TLS or over HTTPS. Nothing connects inward to the site, and no inbound rule has to be added.
No. Logable decodes no LoRaWAN payloads. A LoRaWAN network server can post decoded readings to the HTTPS endpoint, and that works, but the network server stays in the path as a second system to run.
If it has a number and a time, send it to a stream. A stream takes any named value over HTTPS and gets the same charts and the same alert rules a device gets, without a device type having to exist for it.
Open the live demo, or talk to us about the equipment and the gateway you already run.