A resposta curta
Em casa, o AmazHA, uma app Home Assistant para relógios Amazfit, só precisa do seu endereço local, como http://192.168.1.50:8123, e nada tem de estar acessível a partir de fora. Fora de casa, o telemóvel precisa de um endereço remoto a que consiga chegar: o Home Assistant Cloud, uma VPN como o Tailscale ou o WireGuard, ou o seu próprio domínio com HTTPS. Introduza os dois e o AmazHA escolhe sozinho o que funciona.
Em casa não precisa de nada a mais
Na sua rede de casa, o único endereço de que o AmazHA precisa é o que já usa para abrir o Home Assistant num browser em casa. É o campo URL local (LAN) nas definições do AmazHA, e basta por si só: sem subscrição, sem VPN, sem domínio, sem nenhuma porta aberta no router.
O AmazHA tem dois campos de endereço nas definições: URL local (LAN) e URL remoto. Qualquer um pode ficar vazio. Se só usa o relógio em casa, preencha o local, deixe o remoto em branco e está feito. Pode acrescentar um endereço remoto mais tarde, no dia em que quiser que o relógio funcione no escritório ou nas férias, sem mexer em mais nada.
Os campos estão na app Zepp, em Perfil › o seu relógio › Apps › AmazHA › Definições › Home Assistant. Aparecem depois de a versão completa estar desbloqueada (um desbloqueio único, sem subscrição): a versão gratuita é uma demo ao vivo com dados de exemplo e não se liga a nenhum servidor. O tutorial Ligar o Home Assistant mostra em vídeo o passo do endereço local.
Um endereço local típico é parecido com um destes (exemplos, use o seu):
http://192.168.1.50:8123
http://homeassistant.local:8123
Se escrever um endereço sem http:// nem https:// em URL local (LAN), o AmazHA põe-lhe http:// à frente, porque os servidores locais costumam falar http simples.
Porque é o telemóvel que tem de chegar ao Home Assistant
O relógio nunca fala diretamente com o Home Assistant. Fala com o telemóvel por Bluetooth, e a parte do AmazHA que corre dentro da app Zepp, no telemóvel, é a única que envia pedidos para o seu servidor. Por isso, a pergunta «o meu relógio consegue chegar ao Home Assistant?» é, na verdade, «o meu telemóvel consegue chegar ao Home Assistant, agora, a partir de onde está?»
Isto tem algumas consequências práticas:
- O relógio não precisa de Wi-Fi. Nunca se liga a uma rede para o AmazHA. Um relógio só com Bluetooth funciona da mesma maneira.
- O telemóvel tem de estar por perto, com o Bluetooth ligado e a app Zepp a correr. Se não estiver, o relógio diz Offline · O telemóvel não responde, o que é um problema diferente de um endereço errado (veja resolução de problemas, passo 2).
- A rede em que o telemóvel está decide que endereço funciona. No Wi-Fi de casa, funciona o endereço local. Com dados móveis, em casa de um amigo ou no Wi-Fi de um hotel, só um endereço remoto pode funcionar, e só se o telemóvel lhe conseguir chegar a partir daí.
- Uma VPN tem de estar ligada no telemóvel, não no relógio. O relógio não sabe nada dela.
- O seu token fica no telemóvel. Cola um token de acesso de longa duração uma vez, nas definições do AmazHA. O relógio recebe apenas o que mostra, pela ligação Bluetooth que já tem com o telemóvel; o token nunca lhe é enviado.
Isto explica uma situação confusa: as definições dizem Ligado e o relógio diz Offline. As definições testam apenas o caminho do telemóvel até ao Home Assistant; o relógio precisa também do caminho Bluetooth até ao telemóvel.
Como o AmazHA escolhe o endereço
O AmazHA escolhe o endereço sozinho, primeiro o local, depois o remoto. Não há nenhum interruptor para mudar quando sai de casa, e nunca escolhe à mão entre os dois campos.
Com um endereço
Com um só campo preenchido, o AmazHA usa-o e pronto. Nada é sondado e nada é alternado. Uma configuração só local funciona em casa e mostra o banner Offline fora de casa; uma configuração só remota funciona onde quer que o telemóvel consiga chegar a esse endereço.
Com os dois endereços
Com os dois campos preenchidos, o telemóvel pergunta aos dois endereços ao mesmo tempo se o Home Assistant responde, com um limite de tempo curto, de 1,5 segundos. Se o endereço local responder, o AmazHA usa-o. Se só o remoto responder, usa esse. O vencedor fica memorizado, por isso os pedidos seguintes vão diretamente para ele sem voltar a perguntar.
A verificação é mais exigente do que «alguma coisa respondeu». Um endereço só conta quando responde como a API do Home Assistant. Isso importa nas redes dos outros: no Wi-Fi de um hotel, 192.168.1.50 pode ser uma impressora, a página de um router ou um portal cativo que responde com uma página web. O AmazHA não confunde isso com o seu servidor, por isso não fica preso ao seu endereço local quando a resposta certa é o remoto.
Sair de casa e voltar
O endereço memorizado é mantido até um pedido para ele falhar. Quando sai de casa e o telemóvel deixa o seu Wi-Fi, o pedido seguinte para o endereço local falha, o AmazHA esquece-o, e a tentativa seguinte pergunta de novo aos dois endereços e fica no remoto. Enquanto a app AmazHA está aberta, o relógio atualiza a cada 8 segundos, por isso, na prática, a primeira atualização depois da mudança pode falhar e mostrar o banner Offline por instantes, e a seguinte recupera.
Voltar a casa funciona ao contrário, de forma mais discreta: se o seu endereço remoto também funcionar dentro da sua rede, o AmazHA continua a usá-lo até um pedido falhar ou até tocar de novo em Ligar. Não há nada de errado quando isso acontece; o endereço remoto simplesmente continua a funcionar.
Escrever os endereços
Ao preencher os campos, convém saber alguns pormenores:
- Nada depois do endereço do servidor.
http://192.168.1.50:8123, e nãohttp://192.168.1.50:8123/lovelace. O mesmo vale para o remoto:https://xxxxx.ui.nabu.casa, e nãohttps://xxxxx.ui.nabu.casa/lovelace. Com um caminho no fim, o endereço responde, mas não como a API do Home Assistant. - O esquema. Sem esquema escrito, URL local (LAN) recebe
http://e URL remoto recebehttps://. Escreva você mesmohttp://se um endereço remoto for mesmo http simples (um endereço de VPN, por exemplo). - A porta. Mantenha a porta se o seu endereço precisar dela, como em
:8123. Sem porta,https://significa 443. - Um token para os dois. Cole-o uma vez em Token de acesso de longa duração; serve para o endereço local e para o remoto. Os dois endereços têm de levar ao mesmo Home Assistant.
O tutorial Ligar o Home Assistant cobre o passo do endereço remoto, e o passo 8 o teste que se segue.
As opções de acesso remoto comparadas
Qualquer endereço remoto funciona com o AmazHA, desde que o telemóvel o consiga abrir a partir de onde está e que responda como a API do Home Assistant. Qual usar é uma decisão do Home Assistant, não do AmazHA. Eis as mais comuns lado a lado.
| Opção | O que vai em URL remoto | Portas abertas em casa | HTTPS e certificado | Custo | O telemóvel precisa de |
|---|---|---|---|---|---|
| Home Assistant Cloud da Nabu Casa (passa a Home Assistant Link a 2 de dezembro de 2026) | O endereço remoto que gera para si, https://xxxxx.ui.nabu.casa |
Nenhuma | Incluído | Subscrição | Nada a mais |
| VPN, como o Tailscale ou o WireGuard | O endereço do Home Assistant dentro da VPN | Nenhuma com o Tailscale; uma para um servidor WireGuard próprio | O túnel é cifrado; https só se o configurar | Há opções gratuitas | A VPN ligada |
| O seu próprio domínio através de um túnel, como o Cloudflare Tunnel | https://ha.example.com |
Nenhuma | Fornecido pelo túnel | Normalmente um domínio | Nada a mais |
| O seu próprio domínio com um proxy inverso | https://ha.example.com |
Uma (normalmente a 443) | A configurar por si, por exemplo com Let’s Encrypt | Um domínio ou um nome DNS dinâmico gratuito | Nada a mais |
| Reencaminhamento de porta diretamente para o Home Assistant | https://yourname.duckdns.org:8123 |
Uma | A configurar por si | Existe DNS dinâmico gratuito | Nada a mais |
Home Assistant Cloud (em breve Home Assistant Link)
O Home Assistant Cloud é o serviço por subscrição gerido pela Nabu Casa; as subscrições financiam o desenvolvimento a tempo inteiro do Home Assistant. A própria documentação do Home Assistant chama-lhe a opção mais fácil para a maioria das pessoas: não precisa de portas abertas no router, cifra o tráfego e gera um URL remoto único para si.
Para o AmazHA, esse URL remoto é tudo o que precisa: copie-o, tal como o Home Assistant o mostra, para URL remoto, sem nada depois. O seu token de acesso de longa duração funciona através dele exatamente como no endereço local, já que os dois levam ao mesmo servidor.
A 2 de outubro de 2026, a Nabu Casa anunciou que o Home Assistant Cloud passará a chamar-se Home Assistant Link a 2 de dezembro de 2026. O anúncio diz que é a mesma subscrição com um novo nome e que não é preciso fazer nada. Não menciona nenhuma mudança de endereço, por isso hoje não há nada a mudar no AmazHA.
Uma VPN: Tailscale, WireGuard e outras
Uma VPN põe o seu telemóvel na sua rede de casa, virtualmente, esteja onde estiver. A documentação do Home Assistant indica serviços VPN como o Tailscale e o ZeroTier One como uma via de acesso segura, e aponta o senão: a VPN tem de estar ligada antes de qualquer coisa conseguir chegar ao Home Assistant a partir de fora. Para o AmazHA, isso significa que a VPN tem de estar ligada no telemóvel. Se cair, o relógio mostra Offline · Home Assistant inacessível até ela voltar.
O que vai em URL remoto é o endereço que o telemóvel usa para o Home Assistant enquanto a VPN está ligada: o endereço do servidor dentro da VPN, ou um nome que a sua VPN resolve para ele. Dois pormenores:
- Se o seu servidor responder aí em http simples, escreva
http://à frente do endereço. Sem esquema, o AmazHA acrescentahttps://ao endereço remoto, que não responderia. - Com algumas configurações de VPN, o próprio endereço de casa,
192.168.1.50, fica acessível através do túnel. Nesse caso, o endereço local funciona em todo o lado onde a VPN estiver ligada, e o campo remoto serve de alternativa para quando não estiver.
Uma VPN é a opção com menor exposição: nada do seu servidor fica aberto à internet. O preço é que todos os dispositivos que precisam do Home Assistant, incluindo o telemóvel, têm de correr o cliente VPN.
O seu próprio domínio com HTTPS: um proxy inverso ou um túnel
Com o seu próprio domínio, https://ha.example.com leva ao seu Home Assistant a partir de qualquer lado. Duas formas comuns de lá chegar:
- Um proxy inverso (Nginx, Caddy, Traefik ou semelhante) em casa recebe os pedidos na porta 443, trata do certificado e passa os pedidos ao Home Assistant. Precisa de um reencaminhamento de porta no router.
- Um túnel, como o Cloudflare Tunnel, corre um pequeno conector dentro da sua rede que mantém aberta uma ligação de saída ao fornecedor, por isso nada é aberto no router. O fornecedor serve o seu domínio com um certificado válido.
Nos dois casos, há algo à frente do Home Assistant que lhe reencaminha os pedidos, e o Home Assistant tem de ser configurado para confiar nisso. A documentação do Home Assistant é explícita: os pedidos de um proxy inverso são bloqueados, a não ser que ative Trust X-Forwarded-For (confiar em X-Forwarded-For) e adicione o proxy a Trusted proxies (proxies de confiança). Se não o fizer, todos os pedidos através do proxy recebem 400 Bad Request (mais sobre isso abaixo).
Reencaminhamento de porta, por si só
Reencaminhar uma porta do router diretamente para o Home Assistant é a via mais direta, e aquela com que a documentação de acesso remoto do Home Assistant tem mais cuidado: abrir uma porta, por si só, não é seguro, o tráfego tem de ser cifrado e deve percorrer a sua lista de verificação de segurança antes de expor o que quer que seja. Refere ainda duas armadilhas práticas: muitos fornecedores de internet dão-lhe um endereço IP dinâmico, razão pela qual sugere um nome DNS dinâmico como o DuckDNS, e alguns fornecedores põem-no atrás de CG-NAT, onde as ligações de entrada não lhe conseguem chegar de todo.
Se seguir este caminho, o endereço remoto é o seu nome DNS dinâmico com https e a porta que reencaminhou, por exemplo https://yourname.duckdns.org:8123. Ponha exatamente isso em URL remoto.
HTTPS e certificados fora de casa
Fora de casa, a regra do tutorial de resolução de problemas é curta: o endereço precisa de https com um certificado válido. Há duas razões.
A primeira é a segurança. O seu token de acesso de longa duração segue com cada pedido que o telemóvel envia. Em http simples na internet aberta, qualquer pessoa no caminho o pode ler e, com ele, controlar a sua casa.
A segunda é que os telemóveis recusam certificados em que não confiam. Um certificado autoassinado, feito no seu próprio servidor, não está assinado por uma autoridade em que o telemóvel confie de origem, por isso a ligação é recusada antes de chegar ao Home Assistant. No relógio, isso parece um servidor inacessível como outro qualquer. A solução simples é um certificado em que o telemóvel já confie:
- O Home Assistant Cloud e os túneis como o Cloudflare Tunnel fornecem-lhe um.
- Com o seu próprio domínio ou um nome DNS dinâmico, os certificados Let’s Encrypt são gratuitos e os telemóveis confiam neles.
Há duas armadilhas que apanham quem configura o HTTPS no próprio Home Assistant, e não num proxy à frente dele:
- O endereço local também muda. A partir do momento em que o Home Assistant serve HTTPS na sua porta, o
http://192.168.1.50:8123simples deixa de responder nessa porta. - Um endereço IP não corresponde ao certificado. Um certificado para
ha.example.comnão é válido parahttps://192.168.1.50:8123, por isso esse endereço local falha a verificação do certificado. Um proxy inverso ou um túnel para o lado remoto, com o próprio Home Assistant em http simples em casa, evita as duas.
O http simples é normal e serve bem para o endereço local em casa. Dentro de uma VPN, cujo túnel já é cifrado, o http também pode ser aceitável; na internet aberta, use https.
Erros comuns e o que o relógio diz
Quando algo está mal, o relógio diz que ligação falhou. A tabela lista as mensagens que têm a ver com endereços, e a que parece semelhante, mas não é.
| No relógio | O que significa | Solução |
|---|---|---|
| Offline · Home Assistant inacessível · Repete a cada 8 s | O telemóvel não conseguiu chegar ao Home Assistant em nenhum dos endereços que introduziu | Abra o endereço no browser do telemóvel, a partir de onde ele está; fora de casa, https com um certificado válido |
| Endereço errado · Responde, mas não é a API do Home Assistant | Algo respondeu, mas não a API do Home Assistant: normalmente um caminho como /lovelace depois do endereço |
Mantenha apenas o endereço do servidor, sem nada depois |
| Offline · O telemóvel não responde | O relógio não conseguiu chegar ao telemóvel; o endereço não está em causa | Telemóvel por perto, Bluetooth ligado, app Zepp a correr |
| É preciso token admin | O endereço funciona, mas o token pertence a um utilizador sem direitos de administrador | Crie um token de longa duração como administrador |
Offline · Home Assistant inacessível
O banner mostra Offline, depois Home Assistant inacessível · Repete a cada 8 s e, por baixo, um pequeno código que diz ao suporte exatamente o que falhou. As causas habituais: está fora de casa só com um endereço local; a VPN não está ligada no telemóvel; o endereço remoto funciona em casa, mas não a partir de fora; o telemóvel não confia no certificado; ou o próprio Home Assistant está em baixo ou a reiniciar. A solução começa sempre da mesma forma: abrir o endereço no browser do telemóvel, como se descreve abaixo. O tutorial de resolução de problemas, passo 3, mostra esta mensagem em vídeo.
Endereço errado
Endereço errado significa que o endereço respondeu, mas com uma página web em vez da API do Home Assistant. Quase sempre, o endereço leva um caminho, normalmente copiado da barra do browser: https://ha.example.com/lovelace/0 em vez de https://ha.example.com. Apague tudo o que vem depois do endereço do servidor (e da sua porta). Nas definições do AmazHA, o teste de ligação diz o mesmo à sua maneira: o endereço responde, mas não com a API do Home Assistant, e dá o exemplo de um endereço do Home Assistant Cloud com e sem /lovelace. Veja resolução de problemas, passo 4. Menos vezes, o endereço leva a algo completamente diferente, como a página de administração de um router.
400 Bad Request atrás de um proxy inverso
Se o seu endereço remoto passar por um proxy inverso ou por um túnel e todos os pedidos voltarem com 400 Bad Request, é o Home Assistant que está a recusar o proxy. A sua integração HTTP rejeita qualquer pedido que traga um cabeçalho de reencaminhamento quando não foi configurada para confiar em proxies inversos, ou quando o endereço do proxy não está na sua lista de confiança, e a resposta nos dois casos é 400. O registo do Home Assistant indica o endereço de onde veio o pedido; no segundo caso diz «Received X-Forwarded-For header from an untrusted proxy», seguido desse endereço.
No AmazHA, Ligar mostra Erro 400 com um só endereço, ou um ponto vermelho ao lado de Remoto com os dois.
A solução está do lado do Home Assistant. Nas versões atuais, as definições do servidor HTTP estão na interface: em Configuração › Sistema › Rede, ative Trust X-Forwarded-For e adicione o endereço ou a rede do proxy em Trusted proxies. As versões mais antigas usam YAML em configuration.yaml (o endereço abaixo é um exemplo; use o do seu proxy):
http:
use_x_forwarded_for: true
trusted_proxies:
- 192.168.1.10
A documentação da integração HTTP do Home Assistant tem os pormenores para cada versão. Reinicie o Home Assistant se a sua versão o exigir e depois toque de novo em Ligar.
Offline · O telemóvel não responde
Esta não tem nada a ver com endereços. O relógio não conseguiu chegar ao telemóvel por Bluetooth, por isso o telemóvel nem chegou a tentar o Home Assistant. Mantenha o telemóvel por perto, com o Bluetooth ligado e a app Zepp a correr (resolução de problemas, passo 2). Mudar os endereços não resolve.
A definição de URL externo do próprio Home Assistant
O Home Assistant tem as suas próprias definições Home Assistant URL (URL do Home Assistant), com um campo Internet e um campo Local network (rede local), em Configuração › Sistema › Rede. Dizem ao Home Assistant e às suas próprias apps onde ele está. O AmazHA não as lê: usa apenas os dois endereços escritos nas suas próprias definições. Se mudou o URL externo no Home Assistant e o relógio não acompanhou, é por isso. Copie o novo endereço para URL remoto.
Teste primeiro no browser do telemóvel
Antes de mudar o que quer que seja no AmazHA, abra o endereço no browser do mesmo telemóvel, a partir do mesmo sítio. É o teste mais rápido que existe, porque segue o mesmo caminho que o AmazHA: o telemóvel, a rede em que está agora, o seu endereço.
- Desligue o Wi-Fi do telemóvel se estiver a testar o endereço remoto a partir de casa, para que saia mesmo pelos dados móveis. Ligue a VPN se o endereço remoto precisar dela.
- Escreva o endereço exato que introduziu no AmazHA, por exemplo
https://ha.example.com. - Leia o resultado.
| O browser mostra | O que lhe diz |
|---|---|
| A página de início de sessão do Home Assistant | O endereço e o certificado estão bem: o problema está noutro lado (caminho, token, Bluetooth) |
| Um aviso de certificado | O telemóvel não confia no certificado; o AmazHA não pode usar este endereço tal como está |
| Nada, ou «não é possível aceder a esta página» | O telemóvel não consegue chegar ao endereço a partir desta rede |
| 400 Bad Request | Um proxy inverso em que o Home Assistant ainda não confia |
| Outra página (router, fornecedor, página por omissão do proxy) | O endereço leva a outro sítio |
Para o endereço local, faça o mesmo com o Wi-Fi ligado, em casa. Se o browser chegar à página de início de sessão e o AmazHA continuar a falhar, verifique se o campo contém apenas o endereço do servidor, sem nada depois, e o mesmo esquema que o browser usou.
Também pode acrescentar /api/ ao endereço no browser. O Home Assistant responde com um erro de autenticação, já que o browser não envia nenhum token: isso prova que o endereço leva à API do Home Assistant e não a outra página qualquer. No AmazHA, escreva o endereço sem /api/.
O teste de ligação no AmazHA: ler LAN e Remoto
Ligar, nas definições do AmazHA, testa os endereços a partir do telemóvel e diz-lhe o que encontrou. Depois de tocar, o resultado aparece em poucos segundos:
- Com um endereço: Ligado ✓ quando o Home Assistant responde, Inacessível quando nada responde, Erro seguido de um número quando algo respondeu com um erro HTTP (por exemplo Erro 400 ou Erro 401), e Responde, mas não é o Home Assistant quando o endereço responde com algo que não é a API.
- Com os dois endereços: um resultado por endereço, LAN e Remoto, cada um com um ponto colorido: verde quando o Home Assistant responde aí, laranja quando algo responde mas não é o Home Assistant, vermelho quando falha.
Leia-o tendo em conta onde está o telemóvel. Em casa, um Remoto vermelho pode ser normal (um domínio que não dá a volta dentro da sua rede, uma VPN desligada) ou um problema real, por isso teste de novo com o Wi-Fi desligado. Fora de casa, um LAN vermelho é de esperar; aí só conta o Remoto. Os dois verdes, testados uma vez em casa e outra com dados móveis, é a configuração que o acompanha para todo o lado. O passo 8 do tutorial Ligar o Home Assistant mostra o ecrã.
Quando o endereço funciona, mas o token é de um utilizador sem direitos de administrador, Ligar di-lo por baixo do resultado. É um problema do token, não do endereço: o teste do endereço passa, mas o relógio não consegue carregar as suas divisões até o token ser de um administrador.
Quatro configurações, passo a passo
Os mesmos dois campos servem casas muito diferentes. Quatro exemplos, com endereços de exemplo:
Um apartamento, só uso em casa. URL local (LAN): http://192.168.1.50:8123. URL remoto: vazio. O relógio funciona no Wi-Fi de casa; fora, mostra Offline · Home Assistant inacessível, o que é de esperar. Ligar diz Ligado ✓ em casa.
Home Assistant Cloud. URL local (LAN): http://192.168.1.50:8123. URL remoto: https://xxxxx.ui.nabu.casa. Em casa, o AmazHA usa o endereço local; com dados móveis, passa sozinho para o endereço do Home Assistant Cloud. Ligar mostra LAN e Remoto, ambos verdes em casa, porque o endereço da cloud também funciona a partir de dentro.
Uma VPN no telemóvel. URL local (LAN): http://192.168.1.50:8123. URL remoto: o endereço do servidor dentro da VPN, com http:// à frente se o servidor responder aí em http simples. Em casa, ganha o endereço local. Fora, com a VPN ligada, ganha o remoto; com a VPN desligada, o relógio mostra o banner Offline até ela voltar a ser ligada.
O seu próprio domínio atrás de um proxy inverso. URL local (LAN): http://192.168.1.50:8123. URL remoto: https://ha.example.com. Antes de funcionar, o Home Assistant tem de confiar no proxy (Trust X-Forwarded-For, Trusted proxies), ou todos os pedidos remotos recebem 400. Teste o endereço remoto com o Wi-Fi desligado: alguns routers não encaminham o seu próprio domínio de volta para dentro, por isso um Remoto vermelho em casa nem sempre significa que falha lá fora.
Uma lista de verificação antes de sair de casa
Cinco minutos em casa poupam um olhar confuso para o relógio mais tarde:
- URL local (LAN) contém apenas o endereço do servidor, o que o seu browser usa em casa.
- URL remoto contém apenas o endereço remoto: sem
/lovelace, com a porta se precisar dela,https://pela internet. - O browser do telemóvel abre o endereço remoto com o Wi-Fi desligado e mostra a página de início de sessão do Home Assistant, sem nenhum aviso de certificado.
- Se for uma VPN: a VPN está configurada para se manter ligada no telemóvel.
- Se for um proxy inverso ou um túnel: o Home Assistant confia nele, por isso nada de 400.
- Ligar mostra LAN e Remoto a verde, ou Ligado ✓ com um só endereço.
- O token é de um administrador, e é o mesmo para os dois endereços.
Com isto feito, o relógio usa o endereço local em casa e o remoto em todos os outros sítios, sem que tenha de fazer nada. E se um dia mostrar Offline, a segunda linha diz-lhe de que lado procurar: O telemóvel não responde é o Bluetooth, Home Assistant inacessível é o endereço.