MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Reference_designators",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "4322": {
                "pageid": 4322,
                "ns": 0,
                "title": "Reading out Keller series 30 and 40 pressure sensors",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "{{stub}}\n\n\nSearch for the PDF titled [http://www.google.com/search?q=Description%20of%20the%20Communication%20protocol%20for%20Series%2030%20and%20Series%2040%20pressure%20transmitters%20from%20KELLER ''\"Description of the Communication protocol for Series 30 and Series 40 pressure transmitters from KELLER\"'']\n\nThe protocol is based on [[ModBus]] - basically an extension of it, with some footnotes. \n\nThe below describes are notes on basic use and readout. There are more possible interactions, but you can read the full docs for that.\n\n\nThe sensors use a RS485 bus - at 9600 baud (default) or 115200, and 8N1.\n\n\n==Sending and receiving packets==\n\n\nMost generally, packets consist of \n* a '''device address''' (1 byte), \n* a '''function code''' (1 byte), \n** In responses, the lowest 7 bits are the function code, the highest bit signals errors\n* '''payload''' (&ge;0 byte, and apparently &le;6{{verify}})\n* '''crc16''' (2 bytes)\n\n\n\n\nDevice addresses:\n* 0 is for broadcasting\n* 1..249 is for use on a shared bus\n* 250 is for non-bus use (every device responds to this)\n* 251..255 are reserved\n\n\n\nNotes: \n* CRC16: The most generic variant (based on 0xA001 (/0x8005) polynomial, initial value 0xffff; see also [[Hashing_notes#CRC]])\n\n* Packets with invalid CRC16 are discarded\n\n* Request packet is &ge;4 bytes, a response packet &ge;5\n\n* A response message is at most 10 bytes long\n\n\n'''Exception responses''' are five-byte responses: address, function code (with highest bit set), exception code, crc16 high, crc16 low. The error codes relevant here:\n** 1:  function not implemented\n** 2:  bad parameters (e.g. register address)\n** 3:  bad data (frame makes no sense)\n** 32: not initialised (See function 48)\n\n\n\n'''On timing''':\n* time between a response and the next request should be at least 1 byte's worth: ~1ms at 9600 baud and ~0.1ms at 115200 baud.\n* devices have a timeout waiting for the next bytes within the same request: 1.5ms for 9600 baud, 0.20ms at 115200. (if you wait longer, the data will be ignored as a fragment)\n* The sensor is guaranteed to respond within 1..100ms. For all but a few requests, it's much less: 1..3ms\n\n==Keller functions==\n\n===Function 48: Initialize===\nAfter poweron you must send this to initialize a device.\nBasically a \"hey device, acknowledge you're there\", also reading out basic details about type and version.\n\nUntil you send this, any other request will return an error (exception 32)\n\n'''Request packet''', byte-by-byte:\n* ''Device address'' \n* <tt>48</tt>\n* ''CRC16 high byte''\n* ''CRC16 low byte''\n\n'''Response packet''', byte-by-byte:\n* ''Device address''\n* <tt>48</tt>\n* ''Class'' {{comment|(0: prototype, 1:Transmitter, 2:Progres programmer, 3:Manometer, 5:Series 30)}}\n* ''Group'' - ?\n* ''Year'' - software version\n* ''Week'' - software version\n* ''Buf'' - length of transmission buffer\n* ''Status'' - bit 0 signals whether device was already initialised\n* ''CRC16 high byte''\n* ''CRC16 low byte''\n\n<!--\nExample: \n {{key|0xFA}}{{key|0x30}}{{key|0x04}}{{key|0x44}}\n-->\n\n===Function 69: Read serial number===\n\n'''Request packet''', byte-by-byte:\n* ''Device address''\n* <tt>69</tt>\n* ''CRC16 high byte''\n* ''CRC16 low byte''\n\n'''Response packet''', byte-by-byte:\n* ''Device address''\n* <tt>69</tt>\n* ''Four bytes'' (a big-endian uint32)\n* ''CRC16 high byte''\n* ''CRC16 low byte''\n\n\n===Function 73: Sensor readout (floating point)===\n\n'''Request packet''', byte-by-byte:\n* ''Device address''\n* <tt>73</tt>\n* ''channel of the sensor you want to read'':\n** 0 for CH0,  Calculated (what this contains is configured via )\n** 1 for P1,   Pressure on sensor 1\n** 2 for P2,   Pressure on sensor 2\n** 3 for T,    Additional temperature sensor\n** 4 for TOB1, Temperature of pressure sensor 1\n** 5 for TOB2, Temperature of pressure sensor 2\n* ''CRC16 high byte''\n* ''CRC16 low byte''\n\n'''Response packet''', byte-by-byte:\n* ''Device address''\n* <tt>73</tt>\n* ''Byte3 of 32-bit IEEE float'' <!--(see also [[Notes_on_numbers_in_computers#Floating_point_numbers]])-->\n* ''Byte2 of that float''\n* ''Byte1 of that float''\n* ''Byte0 of that float''\n* ''Stat'', which is 8 bits of status:\n** Bit7, <tt>/STD</tt>:  1: in powerup mode. 0: in standard ode\n** Bit6, <tt>ERR2</tt>:  Error calculating analog-out (at saturation)\n** Bit5, <tt>TOB2</tt>:  Error measuring/calculating TOB2 \n** Bit4, <tt>TOB1</tt>:  Error measuring/calculating TOB1\n** Bit3, <tt>T</tt>:     Error measuring/calculating T\n** Bit2, <tt>P2</tt>:    Error measuring/calculating P2\n** Bit1, <tt>P1</tt>:    Error measuring/calculating P1\n** Bit0, <tt>CH0</tt>:   Error measuring/calculating CH0\n* ''CRC16 high byte''\n* ''CRC16 low byte''\n\n\n<!--\n===Function 74: Sensor readout (integer)===\n-->\n\n===Function 95: Calculating functions===\n<!--\nRequest packet, byte-by-byte:\n* Device address \n* CRC16 high byte\n* CRC16 low byte\n\nResponse packet, byte-by-byte:\n* Device address\n* CRC16 high byte\n* CRC16 low byte\n-->\n\n===Function 66: Set new device address===\n<!--\n\nRequest packet, byte-by-byte:\n* Device address \n* new address\n* CRC16 high byte\n* CRC16 low byte\n\nResponse packet, byte-by-byte:\n* Device address (presumably the new one?)\n* 0\n* CRC16 high byte\n* CRC16 low byte\n-->\n\n===Others===\n\nThere are other (Keller-specific) functions (34, 35, 64, 65, 101), but they have no meaning for these sensors.\n\nWhat about 32 and 33?\n\n==MODBUS functions==\n<!--\n===Function 3: register load===\n\n===Function 6: register write (single)===\n\n===Function 8: echo test===\n\n===Function 16: register write (multiple)===\n\n-->"
                    }
                ]
            },
            "8638": {
                "pageid": 8638,
                "ns": 0,
                "title": "Recovery key",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "\n\n<!--\n\n\n\nAn encryption recovery key is usually specific to a singular device.\n\nIt is basically an \"if you forget your password, there is still a way in - which you should probably have in a safe or something\".\n\n\nUpsides\n* If you need data to be unrecoverable by someone else, this avoids there being another way without your knowledge\n\n\nIssues:\n* If you need data to be recoverable and to stored it here, you can't afford to lose it - \n\n* If you need data to be unrecoverable, you are now the only target (for the password)\n\n\n\nAlso consider that 'recovery key' may have different meanings.\n\n\nFor example, on apple accounts, an '''account recovery key''' (shown once and ''never'' again) \nbasically means 'if you  choose this, this becomes the ''only'' way you can every recover your account\".    ''Not'' using one may ease that recovery to, say, 'password plus trusted device' \n(this may change), which isn't as secure but good enough for most people.\n\n\n\n-->"
                    }
                ]
            }
        }
    }
}