> 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/novas-funcionalidades-do-mip-ip/cadastro-em-lote.md).

# Cadastro em lote

#### Premissas

1. Nova flag (`PROT_FLAG_EDITAR_REC_LOTE`) para cadastro em lote dos comandos manutenir (usuário, controle ou chaveiro), somente com as informações obrigatórias (ver tabelas abaixo);
2. Comando manutenir com a flag de editar recurso em lote acima irá salvar as informações em um arquivo temporário;
3. Comandos para atualizar base do MIP: este comando irá transferir os dados dos arquivos temporários para a base corrente de usuários, controles e chaveiros, atualizando os IDs sobrescritos e inserindo os novos IDs. Ao finalizar esse comando a base do MIP IP irá automaticamente atualizar os dispositivos ligados na RS485;
4. Evento de base atualizada: Evento criado e enviado ao software informando que a solicitação de atualizar base foi finalizada;
5. Comando para sincronismo dos dispositivos (todos ou endereço específico): este comando executa o resincronismo de forma forçada nos dispositivos da rede 485, com a base corrente do MIP IP;
6. Em caso de falha gera evento de sync do dispositivo;
7. Comando para excluir base atual.

#### Tabela dos novos comandos

| Descrição                      | Valor |
| ------------------------------ | ----- |
| PROT\_CMD\_ATUALIZAR\_BASE     | 0x52  |
| PROT\_CMD\_SINCRONISMO\_REMOTO | 0x53  |

#### Tabela das novas Flags

| Descrição                     | Valor |
| ----------------------------- | ----- |
| PROT\_FLAG\_EDITAR\_REC\_LOTE | 0x2A  |
| PROT\_FLAG\_EXC\_LOTE         | 0x2B  |

***

### Implementação

#### Comandos implementados

Manutenir Usuário, Tag e RF;

**Comandos manutenir usuário**

Dados é formado por blocos dos dados de usuários, cada bloco de dados possui 68 bytes, com o máximo de usuários enviados num único comando sendo de 25;

`68 * 25 = 1700 + 24 (header) = 1724` (tamanho máximo).

Cada bloco de dados de usuário possui:

| Dado                    | Qtd bytes | Descrição                                                                                                                                                                                                                                                       |
| ----------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Id                      | 4         | Número único de identificação do usuário.                                                                                                                                                                                                                       |
| Nome                    | 34        | Nome do usuário. Tamanho máximo definido pela constante `USUARIO_TAMANHO_NOME`.                                                                                                                                                                                 |
| Apto                    | 5         | Campo que contém o número do apartamento, da casa, ou outra informação configurada para esse campo.                                                                                                                                                             |
| Categoria               | 1         | Define o tipo de usuário. Esse campo contém a categoria a qual o usuário pertence.                                                                                                                                                                              |
| Dispositivos permitidos | 4         | Define em quais dispositivos \[cada posição do vetor] e fechaduras \[cada bit] o usuário tem acesso.                                                                                                                                                            |
| Senha secundária        | 4         | Define a senha do usuário.                                                                                                                                                                                                                                      |
| Dias da Semana          | 1         | Indica em que dias da semana o visitante/prestador pode acessar o condomínio. Cada bit representa um dia da semana.                                                                                                                                             |
| Data Inicial            | 3         | 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              | 3         | 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            | 3         | 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 `0x0E 0F 1A` LSB. |
| Hora final              | 3         | 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.   |
| Reservado               | 3         | Para uso futuro.                                                                                                                                                                                                                                                |

**Exemplo de comando:**

Adicionar usuários em lote (2 usuários: cada usuário usa `68 bytes * 2 = 136 = 0x88` (campo de tamanho dos dados)):

```
A6010001012a0000000040e201010000000088000000020000006d6f7261646f722032320000000000000000000000000000000000000000000000000323200000000f701000000000000ff0109151f0c63080e06173b3b000000030000006d6f7261646f722032320000000000000000000000000000000000000000000000000323200000000f701000000000000ff0109151f0c63080e06173b3b000000D610
```

***

**Comandos manutenir tag dados**

`1692 + 24 (header) = 1716` (máx. 141 tags).

Bloco de dados: `12 bytes * 141 (tags)`.

| Dado       | Qtd bytes | Descrição                                             |
| ---------- | --------- | ----------------------------------------------------- |
| Id         | 4         | Número único de identificação da Tag.                 |
| Id usuário | 4         | Número único de identificação do usuário dono da Tag. |
| Código     | 4         | Campo que contém o código identificador da TAG.       |

***

**Comandos manutenir rf dados**

Bloco de dados: `16 bytes * 107 (rfs) = 1712 + 24 (header) = 1736` (máx. 107 RFs).

| Dado       | Qtd bytes | Descrição                                            |
| ---------- | --------- | ---------------------------------------------------- |
| Id         | 4         | Número único de identificação do RF.                 |
| Id usuário | 4         | Número único de identificação do usuário dono do RF. |
| Código     | 4         | Campo que contém o código identificador do RF.       |
| Timestamp  | 4         | Armazena o valor do timestamp do controle.           |

***

### Observações

1. Para adicionar, os IDs devem ser inseridos em ordem crescente e, se maior que o máximo ID cadastrado, deve ser consecutivo;
2. Arquivos salvos num arquivo temporário aguardando novos comandos de inserção ou para deletar o arquivo em lote atual; excluirá lote salvo anteriormente: comando manutenir com a flag `PROT_FLAG_EXC_LOTE` faz a exclusão do arquivo em lote;
3. Comando atualizar base do MIP: enviar para o MIP o comando `PROT_CMD_ATUALIZAR_BASE`, o MIP irá transferir as informações do arquivo em lote para o arquivo oficial. Esse processo pode demorar para responder. Ao finalizar esse comando, o MIP começará a ressincronizar automaticamente todos os dispositivos; o processo pode ser acompanhado pelo display;
4. Ao finalizar, o MIP cria um evento de base atualizada, evento tipo: `EVENTO_BASE_ATUALIZADA_OK (49 - 0x31)`, e indica qual o arquivo foi alterado no tipo de recurso;
5. Comando de ressincronismo remoto de dispositivos: enviar comando `PROT_CMD_SINCRONISMO_REMOTO` com flag de urgente e campo de dados de 4 bytes com endereço do dispositivo a ser sincronizado. Caso o endereço seja 0 ou 1, será realizado o sincronismo de todos os dispositivos.


---

# 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/novas-funcionalidades-do-mip-ip/cadastro-em-lote.md?ask=<question>&goal=<user_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.
