> For the complete documentation index, see [llms.txt](https://portal-integracao.intelbras.com.br/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://portal-integracao.intelbras.com.br/mip-1000-ip/usuarios/manutenir-usuario.md). # Manutenir Usuário O comando manutenir usuário (MU) é utilizado para realizar as operações de CRUD (acrônimo de Create Read Update Delete) nos dados de um determinado usuário. O valor para identificar o comando **MU** é **0x01**. Esse comando é utilizado sempre que algum dispositivo desejar informar ao outro sobre a inclusão, alteração, busca dos dados ou exclusão de usuário. As manutenções referentes ao cadastro de um usuário podem ser realizadas através de qualquer dispositivo com acesso ao MIP 1000 IP. Esse comando é complementado através de *flags* de apoio que sinalizam a opção desejada, ou seja, através do campo “flag” é sinalizado a operação que se deseja realizar com o usuário, inclusão (INCLUIR\_RECURSO), alteração (ALTERAR\_RECURSO), busca dos dados (BUSCAR\_RECURSO) ou exclusão (EXCLUIR\_RECURSO). As *flags* de exclusão (flag **EXCLUIR\_RECURSO)** ou busca (flag **BUSCAR\_ RECURSO**) necessitam que, ao serem enviadas para o MIP, o campo “**dados**” deste comando contenha somente o ID (4 bytes) do usuário que deseja fazer a operação e consequentemente o campo “**tamanho do campo de dados**” será de 0x04 00. Este comando com a flag de **EXCLUIR\_RECURSO** tem como resposta o datagrama padrão enviado pelo MIP 1000 IP com o campo de dados zerado e com uma das *flags* indicadas abaixo: | SUCESSO | Enviado caso a operação tenha sido realizada com sucesso. | | ----------------------- | --------------------------------------------------------------------------------------------------------------------- | | FALHA | Sinaliza falha na execução da operação solicitada. | | ERRO\_CHKS | Enviado se ocorreu um erro de CHKS na conferência dos dados. | | IDENTIFICADOR\_RECUSADO | Sinaliza que o id (identificador) enviado é inválido, pois já existe um recurso cadastrado no sistema com o mesmo id. | | COMANDO\_INV | Sinaliza o recebimento de um comando inválido, desconhecido. | Este comando com a flag de BUSCAR\_ RECURSO tem como resposta o datagrama padrão enviado pelo MIP 1000 IP e com o campo de dados zerado se o ID não for encontrado ou houver algum problema sinalizado pelas flags já vistas acima, exceto SUCESSO. Caso o comando tenha sido executado com sucesso o datagrama retornará com a flag SUCESSO e com o campo de dados com os seguintes dados com seu tamanho dado em bytes:
IDCPFRGNível de acessoStatusNomeE-mailTel. Res.Tel. Res.
4B6B4B1B1B34B34B5B3 bytes
| Tel. Cel. | Tel. Cel. | Senha Usuário | Data | Apto | Apto \* | Login Menu | Password Menu | Dispositivos liberados | | --------- | --------- | ------------- | ---- | ---- | ------- | ---------- | ------------- | ---------------------- | | 6B | 3 bytes | 2B | 6B | 5B | 1 byte | 10B | 6B | 4B | | Bloco | Categoria | Dias da Semana | Data Inicial | Data Final | Hora Inicial | Hora Final | RG complemento | Senha secundária | | ----- | --------- | -------------- | ------------ | ---------- | ------------ | ---------- | -------------- | ---------------- | | 5B | 1B | 1B | 3B | 3B | 3B | 3B | 4B | 4B | #### Descrição dos campos do comando: | Campo | Descrição | | ------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ID |

Campo que possui um número único identificador do usuário. Sempre maior que zero e seu valor máximo corresponde ao total de usuários cadastrados no MIP 1000 IP. Os dados desse campo possuem o seguinte formato: Exemplo para o ID: 1 MSB 0x01 00 00 00 LSB. (ver nota sobre id’s de visitante no anexo B) | |
ID de visitante sempre maior que 0x8000000

| | | CPF | Campo que contém o número do CPF do usuário. Os dados desse campo possuem o seguinte formato: exemplo para o CPF: 263.159.426-75 => MSB 0x75 26 94 15 63 F2 LSB. Os campos que não forem usados devem ser preenchidos com ‘F’. | | RG |

Campo que contém o RG do usuário. Esse campo conterá apenas os números. Os dados desse campo possuem o seguinte formato: exemplo para o RG: 14.159.760 => MSB 0x60 97 15 14 LSB. Os campos que não forem usados devem ser preenchidos com ‘F’. | |
Olhar RG complemento no final do quadro para RG’s maiores de 8 digitos.

| | | Nível de acesso | Este campo define o nível de acesso do usuário que está sendo cadastrado, e tem influência direta sob as permissões relacionadas à configuração e operação do sistema. Os dados desse campo possuem o seguinte formato: 0x01 para nível de acesso 1, 0x02 para nível de acesso 2, sendo o máximo 0x04. | | Status | Este campo é “oculto” no cadastro de usuários ele deve ser utilizado para sinalizar se o usuário está ativo ou inativo. O status inativo é utilizado para realizar uma exclusão lógica, pois o usuário não pode ser excluído fisicamente do sistema. Os dados desse campo possuem o seguinte formato: 0x00 para registro ativo, 0x01 para inativo. | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Nome | Campo que contém o nome do usuário com caracteres no formato ASCII. Os dados desse campo possuem o seguinte formato: exemplo para o Nome: Paulo => MSB 0x50 61 75 6C 6F 00 ... 00 LSB. As posições (bytes) restantes do campo que não serão utilizados devem ser completadas com 0x00. | | E-mail | Campo que contém o e-mail do usuário. Os dados desse campo possuem o seguinte formato: exemplo para o e-mail: => MSB 0x70 61 75 6C 6F 40 74 65 73 74 65 2E 63 6F 6D 2E 62 72 00 ... 00 LSB. As posições (bytes) restantes do campo que não serão utilizados devem ser completadas com 0x00. | | Telefone Res. |

Campo que contém o telefone residencial do usuário. Os dados desse campo possuem o seguinte formato: exemplo para o telefone residencial: 35 3471 9840 => MSB 0x40 98 71 34 35 00 00 00 LSB. As posições restantes do campo que não serão utilizados devem ser completadas com ‘F’. | |
Este campo está em BCD, onde por exemplo: | | |
D1 == Dígito 1 | | |
D2 == Dígito 2 | | |
D3 == Dígito 3 | | |
TEL\[1] - (D2<<4) | D3 | |
TEL\[0] – 0xF0 | D1

| | Tel. Res. \* campatibilidade | 3 bytes – 0xFF, 0xFF, 0xFF, para manter compatibilidade com protocolo versão 1; | | Tel. Cel. |

Campo que contém o telefone celular do usuário. Os dados desse campo possuem o seguinte formato: exemplo para o telefone celular: 35 9971 1252 => MSB 0x52 12 71 99 35 00 00 00 00 LSB. As posições restantes do campo que não serão utilizados devem ser completadas com ‘F’. | |
Este campo está em BCD, onde por exemplo: | | |
D1 == Dígito 1 | | |
D2 == Dígito 2 | | |
D3 == Dígito 3 | | |
TEL\[1] - (D2<<4) | D3 | |
TEL\[0] – 0xF0 | D1

| | Tel. cel. \* campatibilidade | 3 bytes – 0xFF, 0xFF, 0xFF, para manter compatibilidade com protocolo versão 1; | | Senha |

Campo que contém a senha do usuário para acesso ao condomínio através dos dispositivos com teclado (XLT e XPE ID). A senha deve ser de três dígitos numéricos. Podendo também estar em branco. Este campo está em BCD, que contém a senha de até 3 dígitos numéricos do usuário onde:
D1 == Dígito 1 | |
D2 == Dígito 2 | | |
D3 == Dígito 3 | | |
SENHA\[1] - (D2<<4) | D3 | |
SENHA\[0] – 0xF0 | D1 | |
Os dados desse campo possuem o seguinte formato: exemplo para a senha: 123 => senha\[0] = 0xF3, senha\[1] = 0x12. => MSB 0x23 F1 LSB. Este campo será MSB 0xff ff LSB quando o cadastro for feito pelo MIP indicando assim que os campos que não forem usados devem ser preenchidos com ‘F’.

| | | Campo | Descrição | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Data | Campo que contém a data de cadastro do usuário. Essa data é formada pelos campos: dd -> dia, mm -> mês, aa -> ano, hh -> hora, mm -> minuto, ss -> segundo. Os dados desse campo possuem o seguinte formato: exemplo para a data: 27/06/2012 15:14:26 => **MSB** 0x1B 06 0C 0F 0E 1A **LSB**. | | Apto | Campo que contém o número do apartamento do usuário no caso de condomínio de blocos ou o número da casa no caso de condomínio de casas. O valor é passado em formato ASCII. Os dados desse campo possuem o seguinte formato: exemplo para o apartamento: 11 => **MSB** 0x31 31 00 ... 00 **LSB**. As posições (bytes) restantes do campo que não serão utilizadas devem ser completadas com 0x00. | | Apto \* compatibilidade | 1 byte – 0x00, para manter compatibilidade com protocolo versão 1; | | Login | Campo que contém o nome do usuário que terá acesso as configurações e manipulação do MIP, os caracteres devem estar no formato ASCII. Os dados desse campo possuem o seguinte formato: exemplo para o Nome: Paulo => **MSB** 0x50 61 75 6C 6F 00 ... 00 **LSB**. As posições (bytes) restantes do campo que não serão utilizadas devem ser completadas com 0x00. | | *Password* | Campo que contém o *password* do usuário que terá acesso as configurações e manipulação do MIP, os caracteres devem estar no formato ASCII. Os dados desse campo possuem o seguinte formato: exemplo para a password: 123 => **MSB** 0x31 32 33 ... 00 **LSB**. As posições (bytes) restantes do campo que não serão utilizados devem ser completadas com 0x00. | | Dispositivos Liberados | Indica quais dispositivos do sistema o usuário terá acesso. Esse campo é formado por 4 bytes (32 bits), onde cada bit setado da palavra representa qual endereço de dispositivo o usuário terá acesso, exemplo: se o usuário tem acesso ao XLT da garagem de endereço 2 e ao XPE da entrada de endereço 4, o campo “dispositivos liberados” terá o seguinte valor: **MSB** 0x00... 0x14 **LSB**. Em binário: **MSB** 0 .... 0101 0100 => bit 2 e bit 4 setados. Caso o acesso for somente ao endereço 5: **MSB** 0x00... 0x20 **LSB**. Em binário: **MSB** 0 .... 0010 0000 => bit 5 setado. | | Bloco | Campo que contém o bloco do usuário com caracteres no formato ASCII. Os dados desse campo possuem o seguinte formato: exemplo para o Bloco: A => **MSB** 0x41 0x00 ... 0x00 LSB. As posições (bytes) restantes do campo que não serão utilizados devem ser completadas com 0x00. | | Campo | Descrição | | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Categoria |

Indica em que dias da semana o visitante/prestador pode acessar o condomínio. Cada bit representa um dia da semana da seguinte forma: | |
0b00000001 - Domingo | | |
0b00000010 - Segundas | | |
0b00000100 - Terça | | |
0b00001000 - Quarta | | |
0b00010000 - Quinta | | |
0b00100000 - Sexta | | |
0b01000000 – Sábado | | |
É possível combinar os dias: | | |
0b00000011 – Domingo e Segunda | | |
Também é possível validar dias de feriado, mas para isso é preciso ter também dias da semana liberado por exemplo; | | |
0b10101010 – Segunda, quarta, sexta e feriados | | |
Para liberar todos os dias: | | |
0b11111111 | | |
Todos os dias exceto feriados: | | |
0b01111111

| | | Dias da Semana | Determina a data inicial de acesso do visitante/prestador. Essa data é formada pelos campos: dd -> dia, mm -> mês, aa -> ano. Os dados desse campo possuem o seguinte formato: exemplo para a data: 27/06/2012 => MSB 0x1B 06 0C LSB. | | Data Inicial | Determina a data inicial de acesso do visitante/prestador. Essa data é formada pelos campos: dd -> dia, mm -> mês, aa -> ano. Os dados desse campo possuem o seguinte formato: exemplo para a data: 27/06/2012 => MSB 0x1B 06 0C LSB. | | Data Final | Determina a data final de acesso do visitante/prestador. Essa data é formada pelos campos: dd -> dia, mm -> mês, aa -> ano. Os dados desse campo possuem o seguinte formato: exemplo para a data: 27/06/2012 => MSB 0x1B 06 0C LSB. | | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Hora Inicial | Determina a hora inicial de cada dia do acesso do visitante/prestador. Essa hora é formada pelos campos: hh -> hora, mm -> minuto, ss -> segundo. Os dados desse campo possuem o seguinte formato: exemplo para a data: 15:14:26 => MSB 0x0F 0E 1A LSB. | | Hora Final | Determina a hora final de cada dia do acesso do visitante/prestador. Essa hora é formada pelos campos: hh -> hora, mm -> minuto, ss -> segundo. Os dados desse campo possuem o seguinte formato: exemplo para a data: 15:14:26 => MSB 0x0F 0E 1A LSB. | | RG complemento | Para RG’s com mais de 8 digitos foi criado o RG complemento, onde pode-se inserir os demais digitos do RG. Esse campo conterá apenas os números. Os dados desse campo possuem o seguinte formato: exemplo para o RG: 14159760 987 Os primeiros 8 digitos ficaram no campo RG, e os digitos “987” serão preenchidos no campo RG complemento da seguinte forma => MSB 0xFF FF 7F 98 LSB. Os campos que não forem usados devem ser preenchidos com ‘F’. | | Senha Secundaria |

Campo que contém a segunda opção de senha do usuário para acesso ao condomínio através dos dispositivos com teclado (XLT e XPE ID). A senha deve ser de no minimo quatro dígitos numéricos. Podendo também estar em branco, neste caso preenchida com valor zero. Este campo está em decimal, sendo a senha: “537.681” => 0x0008 3451 => MSB 0x51 0x34 0x08 0x00 LSB | |
Obs.: Esta senha funciona somente se a senha principal estiver zerada.

| | Este comando com a flag de INCLUIR\_RECURSO ou ALTERAR\_RECURSO ao ser enviado para o MIP 1000 IP, permite com que um usuário seja incluído e editado respectivamente. Em ambos os casos o datagrama a ser enviado para o MIP 1000 IP deve ter no seu campo de dados deve ser montado conforme padrão descrito acima. O campo **ID**, quando houver a edição dos dados de um usuário deve-se sempre ter o ID válido deste usuário. Se a operação for de inclusão, este campo ID deve ser o valor do **total de usuários do sistema mais um**. Caso o id enviado não seja um id valido o MIP 1000 IP irá responder o comando com flag IDENTIFICADOR\_INVALIDO e o campo de dados da seguinte maneira: #### Id moradores ID vistantes/prest 4B 4B #### Descrição dos campos do comando: ID moradores: Campo que possui um número único do próximo identificador do recurso. Exemplo para o ID: 1 **MSB** 0x01 00 00 00 **LSB.** ID visitantes: Campo que possui um número único do próximo identificador do recurso. Exemplo prestadores para o ID: 1 **MSB** 0x01 00 00 80 **LSB.** Para saber quantos usuários temos cadastrados, use o comando **VS** (Verificar Sincronismo) que está descrito abaixo neste documento. Com o uso destas *flags* de inclusão ou alteração, o MIP 1000 IP pode retornar todas as *flags* abaixo, mostrando se o comando foi efetivo ou não. O datagrama terá o tamanho padrão com as *flags*: | SUCESSO | Enviado caso a operação tenha sido realizada com sucesso. | | ----------------------- | --------------------------------------------------------------------------------------------------------------------- | | FALHA | Sinaliza falha na execução da operação solicitada. | | ERRO\_CHKS | Enviado se ocorreu um erro de CHKS na conferência dos dados. | | IDENTIFICADOR\_RECUSADO | Sinaliza que o id (identificador) enviado é inválido, pois já existe um recurso cadastrado no sistema com o mesmo id. | | COMANDO\_INV | Sinaliza o recebimento de um comando inválido, desconhecido. | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://portal-integracao.intelbras.com.br/mip-1000-ip/usuarios/manutenir-usuario.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.