TRIGGERcmd - Service Status — Global Monitoring, High Availability, and Reliability

igorneth

Anytime! @Russ

igorneth

TRIGGERcmd - Service Status — Global Monitoring, High Availability, and Reliability

Hello, everyone in the TRIGGERcmd community!

I'd like to share a project I've started because I really appreciate the work Rus does and makes available to everyone in this community.

I took the initiative and decided to register the domain triggercmdstatus.com to create a public monitoring platform that allows us to track the availability of essential services, APIs used by our automations, and other components that are important to the TRIGGERcmd ecosystem.

The goal is to contribute to the community by providing a centralized view of service availability and helping identify potential issues that could affect our automations, including those triggered through voice assistants.

1. Domain and Infrastructure:

The triggercmdstatus.com domain is managed through Cloudflare, with DNSSEC enabled, adding an extra layer of protection to DNS resolution.

To build the infrastructure, I provisioned three servers distributed across different geographic regions:

Oracle Cloud — Instance 1: 1 GB RAM and 1 OCPU.
Oracle Cloud — Instance 2: 1 GB RAM and 1 OCPU.
KingHost — VPS: 4 GB RAM and 2 vCPUs.
All instances have been optimized at the Kernel, Swap, CPUs, and RAM Levels.

These three servers form a distributed architecture designed to improve availability and provide geographic redundancy.

The goal is to reduce dependence on a single server or location, making the monitoring infrastructure more resilient to potential failures and regional outages.

2. Project Goals:

This project was created with the following goals in mind:

Monitor the availability of major global services used by the community.
Track the APIs that support automations integrated with the TRIGGERcmd.com platform.
Check DNS resolution services and network connectivity.
Use distributed probes to collect connectivity metrics from different locations.
Make it easier to identify potential failures in monitored services.
Help distinguish external service issues from potential instability in a user's home internet connection.
Provide a public dashboard that is easy to access without depending on a specific computer.

It's important to note that monitoring helps with troubleshooting, but it cannot independently determine the root cause of every failure. Results should be evaluated alongside local network conditions and the other services involved.

3. Platforms and Technologies:

The infrastructure runs Ubuntu 24.04.5 LTS as its operating system and uses Docker to run services in containers.

3.1. Uptime Kuma — Open-Source Monitoring Platform

Uptime Kuma provides the status dashboard and monitors the configured services.

Version: 2.5.5
Official project: https://github.com/louislam/uptime-kuma
Credits: Louis Lam and the project contributors.

The platform allows users to check monitor statuses, review availability information, and identify potential interruptions affecting monitored services.

3.2. Cloudflare Tunnel — Secure Application Access

Public access to the application is provided through Cloudflare Tunnel, running in a Docker container.

Platform: Cloudflare One — Zero Trust
Dashboard: https://dash.cloudflare.com/one
Credits: Cloudflare, Inc.

Cloudflare Tunnel allows the application to be published without directly exposing inbound server ports to the internet, depending on the configuration in use.

I've also configured Cloudflare features to improve dashboard delivery and availability:

Two-hour cache: Designed to reduce repeated requests to the origin infrastructure and lower resource consumption.
Cloudflare CDN: Used to optimize content delivery to visitors in different geographic locations.
HTTPS with an SSL/TLS certificate: Protects communication between visitors and the public endpoint.

Cache rules are configured with the behavior of the served resources in mind. Dynamic content and monitoring responses must be handled appropriately to prevent outdated information from being displayed as if it were current.

The goal is to balance performance, reduced server load, and the reliability of the information displayed.

3.3. Globalping — Distributed Monitoring

Globalping Probe is also integrated into the infrastructure and runs in a Docker container. It complements the monitoring setup with connectivity metrics collected from different locations.

Project and platform: https://globalping.io
Credits: Globalping.io and its contributors.

Using a distributed monitoring probe provides a broader perspective on service availability, helping reveal conditions that might not be noticeable from a single home internet connection.

4. Monitor Organization:

During the initial phase of the project, 12 monitors were configured and organized into four groups to make the dashboard easier to navigate.

Group 1 — Server

This group monitors the infrastructure components.

Uptime Kuma - Cluster: Monitors the cluster infrastructure.
Cloudflare - Tunnel: Tracks the availability of the tunnel used to access the application.
Globalping - Probe: Tracks the availability of the probe used for global monitoring metrics.

Group 2 — API

This group monitors API services used by the ecosystem and its automations.

TRIGGERcmd.com API: Monitors the availability of the TRIGGERcmd API.
MeuIP.com API: Monitors the availability of the MeuIP.com API.
IPinfo.io API: Monitors the availability of the IPinfo.io API.

These monitors help identify outages affecting services accessed by automations and scripts that depend on these APIs.

Group 3 — ICMP

This group checks ICMP connectivity to public DNS servers.

Cloudflare - DNS: Checks ICMP connectivity to Cloudflare's DNS service.
Google - DNS: Checks ICMP connectivity to Google's public DNS service.

These tests provide information about connectivity to the configured destinations. However, an ICMP response failure does not necessarily mean that the DNS service itself is unavailable, since ICMP traffic may be filtered.

Group 4 — Resolution

This group monitors DNS name resolution.

Cloudflare - Resolution: Monitors DNS resolution using Cloudflare.
Google - Resolution: Monitors DNS resolution using Google.
TRIGGERcmd.com - Cloudflare: Checks resolution of the TRIGGERcmd.com domain through Cloudflare.
TRIGGERcmd.com - Google: Checks resolution of the TRIGGERcmd.com domain through Google.

This organization makes it possible to monitor both resolver availability and the ability to resolve the specific TRIGGERcmd.com domain.

Comparing the results can help identify DNS resolution issues that may prevent access to services even when general internet connectivity is available.

5. Public Access and Compatibility

The dashboard is publicly available at:

https://dash.triggercmdstatus.com

The interface is designed for use across different devices, including:

Desktop and laptop computers.
Smartphones and tablets.
Smart TVs with compatible web browsers.
IoT devices with a compatible browser or another supported way to access the page.

The dashboard is responsive and works with most modern web browsers, adapting its layout to different screen sizes.

The goal is to allow anyone in the community to check service statuses without installing a dedicated application.

6. Why would this monitoring be important?

Anyone who uses TRIGGERcmd with Alexa, other voice assistants, scripts, and automations knows that a failure does not always originate from the computer or device responsible for executing a command.

In some cases, the problem may be related to:

API outages.
DNS resolution issues.
Connectivity failures between networks.
Instability in third-party services.
Regional outages or access infrastructure problems.

A centralized dashboard with distributed monitors makes it easier to gather information that can help investigate these situations.

For example, if an automation stops working, checking the dashboard may provide useful clues about the availability of the monitored services at that moment. This does not replace local troubleshooting, but it provides an additional source of information for diagnosing the problem.

7. Final Thoughts:

This project was inspired by my appreciation for TRIGGERcmd and the work that @Russ and all the Developers make available to the community.

The goal is not to replace existing tools, but to contribute a complementary, public, and accessible resource that can be useful to all of us.

The infrastructure was designed with geographic redundancy, service monitoring, DNS resolution checks, and content delivery features to provide a more reliable monitoring experience.

I plan to continue improving the project by adding new monitors and refining the monitoring mechanisms as new needs arise.

Feel free to visit the dashboard:

https://dash.triggercmdstatus.com

I hope this resource proves useful to the community and helps us better understand the availability of the services involved in our automations.

Special thanks to @Russ and all the Developers for developing and maintaining TRIGGERcmd, as well as to all the developers and contributors behind the open-source tools and services used in this project.

Thank you, everyone!

Author: Igor Neth dos Santos
Alma Mater: UniCesumar — Technology Degree in Computer Networks (2015–2018)
Project: TRIGGERcmd - Service Status | https://dash.triggercmdstatus.com

LinkedIn:
https://www.linkedin.com/in/igorneth

igorneth

TRIGGERcmd - Service Status — Monitoramento Global, Alta Disponibilidade e Confiabilidade

Olá, pessoal da comunidade TRIGGERcmd!

Gostaria de compartilhar com vocês um projeto que iniciei por gostar muito do trabalho que o Rus desenvolve e disponibiliza para todos nós desta comunidade.

Tomei a iniciativa e liberdade de registrar o domínio triggercmdstatus.com, com o objetivo de criar uma plataforma pública de monitoramento que nos permita acompanhar a disponibilidade de serviços essenciais, APIs utilizadas em nossas automações e outros componentes importantes para o funcionamento do ecossistema TRIGGERcmd.

A ideia é contribuir com a comunidade, oferecendo uma visão centralizada da disponibilidade desses serviços e ajudando a identificar possíveis instabilidades que possam afetar nossas automações, inclusive aquelas executadas por meio de assistentes de voz.

1. Domínio e Infraestrutura:

O domínio triggercmdstatus.com está vinculado à plataforma Cloudflare, com DNSSEC habilitado, acrescentando uma camada de proteção à resolução de nomes de domínio.

Para compor a infraestrutura, foram provisionados três servidores distribuídos em diferentes regiões geográficas:

Oracle Cloud — Instância 1: 1 GB de RAM e 1 OCPU.
Oracle Cloud — Instância 2: 1 GB de RAM e 1 OCPU.
KingHost — VPS: 4 GB de RAM e 2 vCPU.
Todas as Instâncias foram otimizadas o Kernel, Swap, Processadores e Memória RAM

Esses três servidores compõem uma arquitetura distribuída, concebida para proporcionar maior disponibilidade e redundância geográfica.

A proposta é reduzir a dependência de um único servidor ou localidade, permitindo que a infraestrutura de monitoramento tenha maior resiliência diante de eventuais falhas ou indisponibilidades regionais.

2. Objetivos do Projeto:

O projeto foi idealizado com os seguintes objetivos:

Monitorar a disponibilidade dos principais serviços globais utilizados pela comunidade.
Acompanhar as APIs que dão suporte às automações integradas à plataforma TRIGGERcmd.com.
Verificar a disponibilidade dos serviços de resolução DNS e conectividade de rede.
Utilizar sondas distribuídas para obter métricas de conectividade a partir de diferentes localidades.
Facilitar a identificação de possíveis falhas nos serviços monitorados.
Ajudar a diferenciar problemas nos serviços externos de possíveis instabilidades na conexão de internet residencial.
Disponibilizar um painel público, acessível de forma simples, sem depender de um computador específico.

É importante destacar que o monitoramento auxilia no diagnóstico, mas não determina sozinho a origem de uma falha. Os resultados devem ser interpretados em conjunto com as condições da rede local e os demais serviços envolvidos.

3. Plataformas e Tecnologias Utilizadas:

A infraestrutura utiliza Ubuntu 24.04.5 LTS como sistema operacional e Docker para executar os serviços em contêineres.

3.1. Uptime Kuma — Plataforma de Monitoramento (Open Source)

O Uptime Kuma é responsável pela apresentação do painel de status e pelo monitoramento dos serviços configurados.

Versão utilizada: 2.5.5
Projeto oficial: https://github.com/louislam/uptime-kuma
Créditos: Louis Lam e colaboradores do projeto.

A plataforma permite acompanhar o estado dos sensores, consultar informações de disponibilidade e visualizar possíveis interrupções nos serviços monitorados.

3.2. Cloudflare Tunnel — Acesso Seguro à Aplicação

O acesso público à aplicação é realizado por meio do Cloudflare Tunnel, executado em contêiner Docker.

Plataforma: Cloudflare One — Zero Trust
Painel: https://dash.cloudflare.com/one
Créditos: Cloudflare, Inc.

O túnel permite publicar a aplicação sem exigir a exposição direta de portas de entrada do servidor à internet, conforme a configuração adotada.

Também foram utilizadas funcionalidades da Cloudflare para aprimorar a entrega e a disponibilidade do painel:

Cache configurado para duas horas: destinado a reduzir solicitações repetidas à infraestrutura de origem e aliviar o consumo de recursos.
CDN da Cloudflare: utilizada para otimizar a entrega de conteúdo aos visitantes distribuídos geograficamente.
HTTPS com certificado digital SSL/TLS: para proteger a comunicação entre os visitantes e o endereço público.

As regras de cache são aplicadas considerando o comportamento dos recursos disponibilizados. Conteúdos dinâmicos e respostas de monitoramento precisam ser tratados adequadamente para evitar que informações desatualizadas sejam apresentadas como se fossem resultados atuais.

O objetivo é equilibrar desempenho, redução de carga e confiabilidade das informações exibidas.

3.3. Globalping — Monitoramento Distribuído

Também foi integrado o Globalping Probe, executado em contêiner Docker, para complementar o monitoramento com métricas de conectividade obtidas a partir de diferentes localidades.

Projeto e plataforma: https://globalping.io
Créditos: Globalping.io e seus colaboradores.

A utilização de uma sonda de monitoramento distribuído ajuda a ampliar a perspectiva sobre a disponibilidade dos serviços, permitindo observar condições que podem não ser perceptíveis a partir de uma única conexão residencial.

4. Organização dos Sensores:

Na primeira etapa do projeto, foram configurados 12 sensores, organizados em quatro grupos para facilitar a leitura do painel.

Grupo 1 — Server

Responsável pelo acompanhamento dos componentes da infraestrutura.

Uptime Kuma - Cluster: monitora a infraestrutura do cluster.
Cloudflare - Tunnel: acompanha a disponibilidade do túnel utilizado para acesso à aplicação.
Globalping - Probe: acompanha a disponibilidade da sonda utilizada nas métricas globais.

Grupo 2 — API

Responsável por acompanhar os serviços de API utilizados no ecossistema e em automações.

TRIGGERcmd.com API: monitora a disponibilidade da API do TRIGGERcmd.
MeuIP.com API: monitora a disponibilidade da API do MeuIP.com.
IPinfo.io API: monitora a disponibilidade da API do IPinfo.io.

Esses sensores ajudam a identificar indisponibilidades nos serviços consultados pelas automações e pelos scripts que dependem dessas APIs.

Grupo 3 — ICMP

Responsável pelos testes de conectividade ICMP com servidores DNS públicos.

Cloudflare - DNS: verifica a conectividade ICMP com o serviço DNS da Cloudflare.
Google - DNS: verifica a conectividade ICMP com o serviço DNS público do Google.

Esses testes fornecem informações sobre a conectividade com os destinos configurados. Uma eventual falha de resposta ICMP não significa necessariamente que o serviço DNS esteja indisponível, pois esse tipo de tráfego pode ser filtrado.

Grupo 4 — Resolution

Responsável pelos testes de resolução de nomes DNS.

Cloudflare - Resolution: monitora a resolução DNS utilizando a Cloudflare.
Google - Resolution: monitora a resolução DNS utilizando o Google.
TRIGGERcmd.com - Cloudflare: verifica a resolução do domínio TRIGGERcmd.com por meio da Cloudflare.
TRIGGERcmd.com - Google: verifica a resolução do domínio TRIGGERcmd.com por meio do Google.

Essa divisão permite observar tanto a disponibilidade dos resolvedores quanto a capacidade de resolver especificamente o domínio TRIGGERcmd.com.

A comparação entre os resultados pode ajudar a identificar problemas de resolução de nomes que, em determinadas circunstâncias, afetam o acesso aos serviços mesmo quando existe conectividade com a internet.

5. Acesso Público e Compatibilidade:

O painel está disponível publicamente no seguinte endereço:

https://dash.triggercmdstatus.com

A interface foi disponibilizada para utilização em diferentes dispositivos, incluindo:

Computadores e notebooks.
Celulares e tablets.
Smart TVs com navegador compatível.
Dispositivos IoT que disponham de navegador ou mecanismo compatível de acesso à página.

O painel é responsivo e pode ser consultado pela maioria dos navegadores modernos, adaptando sua apresentação ao tamanho da tela.

A intenção é permitir que qualquer integrante da comunidade possa consultar o estado dos serviços sem precisar instalar uma aplicação específica.

6. Por que esse monitoramento seria importante?

Quem utiliza o TRIGGERcmd em conjunto com Alexa, outros assistentes de voz, scripts e automações sabe que uma falha nem sempre está no computador ou no equipamento responsável por executar o comando.

Em determinadas situações, o problema pode estar relacionado a:

Indisponibilidade de uma API.
Problemas de resolução DNS.
Falhas de conectividade entre redes.
Instabilidades em serviços de terceiros.
Interrupções regionais ou problemas na infraestrutura de acesso.

Com um painel centralizado e sensores distribuídos, torna-se mais fácil reunir informações que auxiliem na investigação dessas ocorrências.

Por exemplo, se uma automação deixar de funcionar, a consulta ao painel poderá fornecer indícios sobre a disponibilidade dos serviços monitorados naquele momento. Isso não substitui os testes locais, mas oferece mais uma fonte de informação para o diagnóstico.

7. Considerações finais:

Este projeto nasceu da minha admiração pelo TRIGGERcmd e pelo trabalho que o @Russ todos os Desenvolvedores disponibilizam para toda a comunidade.

A proposta não é substituir ferramentas existentes, mas contribuir com um recurso complementar, público e acessível, que possa ser útil para todos nós.

A infraestrutura foi planejada com redundância geográfica, monitoramento de serviços, resolução DNS e recursos de distribuição de conteúdo, buscando oferecer uma experiência de consulta mais confiável.

Pretendo continuar aprimorando o projeto, adicionando novos sensores e aperfeiçoando os mecanismos de monitoramento conforme as necessidades identificadas.

Fiquem à vontade para acessar o painel:

https://dash.triggercmdstatus.com

Espero que esse recurso seja útil para a comunidade e ajude todos nós a compreender melhor a disponibilidade dos serviços envolvidos em nossas automações.

Um agradecimento especial ao @Russ e todos os Desenvolvedores, pelo desenvolvimento e pela manutenção do TRIGGERcmd, e a todos os desenvolvedores e colaboradores das ferramentas de código aberto e serviços utilizados neste projeto.

Obrigado a todos!

Autor: Igor Neth dos Santos
Alma Mater: UniCesumar - Superior de Tecnologia em Redes de Computadores (2015 - 2018)
Projeto: TRIGGERcmd - Service Status | https://dash.triggercmdstatus.com

LinkedIn:
https://www.linkedin.com/in/igorneth

igorneth

@Russ said:

I created a separate app for triggering commands called TRIGGERcmd Misson Control.

Now you can use it to generate commands using AI - checkout this video.

Perfect work!

igorneth

@Russ said:

@igorneth, if you close and open the agent it should download the updated list of examples.

Thank you very much for the instructions!

The instructions for conducting the search and the operation worked perfectly!

Thank you so much again, Russ!

igorneth

@Russ said:

@igorneth, I added it. Let me know if you want me to make any changes.

Wow! It's perfect, my friend!

Thank you so much for everything!

However, I still haven't been able to find it in the search.

igorneth

@Russ said:

@igorneth nice job!

Thank you very much, my friend Russ!

I’m really glad you liked it! Truly!

I'm currently trying, working and adapting on a translation into American English, so that the community can understand and enjoy the project and any future versions.

It would be really cool and interesting to make this example available within the software's GUI, with a link to the documentation post! What do you think of that idea?

Thank you so much again!

igorneth

INTRODUÇÃO

Este tutorial demonstra como utilizar o TRIGGERcmd para executar um script PowerShell capaz de consultar o endereço IP Público de um Provedor de Internet - ISP, através de um computador e retornar o resultado para o TRIGGERcmd.

A solução utiliza duas APIs:

MEU IP - responsável por obter o endereço IP Público.
IPinfo.io - responsável por identificar a Organização / ISP associada ao endereço IP.

O resultado final será enviado ao TRIGGERcmd no seguinte formato:

$RESULTADO_MEUIP - $ORGANIZAÇÃO

Por exemplo:

123.456.789.123 - XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX

O resultado poderá então ser utilizado pelo recurso Voice/MCP Reply, permitindo que o Alexa fale a informação ao usuário.

1 - COMO FUNCIONA:

O funcionamento da solução é dividido em etapas:

ALEXA
   ↓
TRIGGERcmd
   ↓
POWERSHELL
   ↓
MEU IP API
   ↓
ENDEREÇO IP PÚBLICO
   ↓
IPINFO.IO API
   ↓
ORGANIZAÇÃO / ISP
   ↓
POWERSHELL
   ↓
SendResult.bat
   ↓
TRIGGERcmd
   ↓
{{result}}
   ↓
ALEXA

O PowerShell é responsável pela lógica principal.

O SendResult.bat é responsável por enviar o resultado processado de volta para o TRIGGERcmd.

2 - PRÉ-REQUISITOS:

Antes de começar, você deverá possuir:

Uma conta no TRIGGERcmd.
O TRIGGERcmd Agent instalado no computador.
PowerShell disponível no Windows.
Acesso à Internet.
Um comando configurado no TRIGGERcmd.
O arquivo SendResult.bat disponível no diretório do TRIGGERcmd.
Skills ativas: TRIGGERcmd Smart Home e Execute Comando

O diretório utilizado pelo TRIGGERcmd neste projeto é:

%USERPROFILE%\.TRIGGERcmdData\

3 - ARQUIVO SendResult.bat:

O SendResult.bat é responsável por enviar o resultado do comando para a API do TRIGGERcmd.

O arquivo deve estar localizado em:

%USERPROFILE%\.TRIGGERcmdData\SendResult.bat

Exemplo:

@echo off

if "%~1"=="" goto noparams
goto yesparams

:noparams
echo You need to specify the command result as a quoted sentence.
echo Example:
echo SendResult.bat "This is the result of my command."
goto end

:yesparams

set /p TCMD_TOKEN=<"%USERPROFILE%\.TRIGGERcmdData\token.tkn"

curl -X POST "https://www.triggercmd.com/api/command/result" ^
-H "Authorization: Bearer %TCMD_TOKEN%" ^
-H "content-type: multipart/form-data" ^
-F "computer_id=%TCMD_COMPUTER_ID%" ^
-F "command_id=%TCMD_COMMAND_ID%" ^
-F "result=%~1" ^
>>"%USERPROFILE%\.TRIGGERcmdData\results.log" 2>&1

:end

IMPORTANTE: não é necessário modificar esse arquivo para utilizar o script deste tutorial - Caso queira substituir o conteúdo, não há problema.

4 - CRIANDO O SCRIPT POWERSHELL:

Crie um arquivo com a extensão:

.ps1

Por exemplo (C:\SCRIPTS\IP_PUBLICO.ps1):

IP_PUBLICO.ps1

Utilize o seguinte código:

# =====================================================================
# NOME DO PROJETO         : CONSULTA DE IP PÚBLICO - TRIGGERcmd
# AUTOR                   : IGOR NETH DOS SANTOS
# ALMA MATER              : UniCesumar - Superior de Tecnologia em Redes de Computadores (2015 - 2018)
# APOIO                   : EDSON ALEXANDRE DOMINGUES MORENO - Professor Moreno
# PAÍS                    : BRASIL
# VERSÃO                  : 1.1.0
# DATA                    : 03/09/2026 - 3 de Setembro de 2026
#
# DESCRIÇÃO:
#    ESTE SCRIPT CONSULTA O ENDEREÇO IP PÚBLICO ATRAVÉS DA API DO SITE MEU IP
#    E CONSULTA A ORGANIZAÇÃO RESPONSÁVEL PELO IP ATRAVÉS DA API IPINFO.IO.
#
#    O RESULTADO FINAL É ENVIADO PARA O TRIGGERCMD ATRAVÉS DO SendResult.bat.
#
# SITE MEU IP: https://meuip.com | API MEU IP: https://meuip.com/api/meuip.php
#
# SITE IPINFO: https://ipinfo.io | API IPINFO: https://ipinfo.io
#
# FORMATO DO RESULTADO: IP - ORGANIZAÇÃO | EXEMPLO: 123.456.789.123 - NOME DO ASN
#
# OBSERVAÇÃO:
#    A API IPINFO.IO RETORNA O PARÂMETRO "org" NO SEGUINTE FORMATO:
#
#    AS123456 XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX
#
#    O SCRIPT REMOVE AUTOMATICAMENTE O PREFIXO "AS" E OS NÚMEROS,
#    MANTENDO SOMENTE O NOME DA ORGANIZAÇÃO:
#
# OBSERVAÇÃO:
#    O SCRIPT ENVIA O RESULTADO PARA O TRIGGERCMD SEM A FRASE EM
#    PORTUGUÊS QUE SERÁ FALADA PELA ALEXA.
#
#    A FRASE QUE SERÁ FALADA PELA ALEXA É CONFIGURADA DIRETAMENTE
#    NO CAMPO "VOICE/MCP REPLY" DO TRIGGERCMD, UTILIZANDO {{result}}.
#
# EXEMPLO DE VOICE/MCP REPLY: SEU IP PÚBLICO É: {{result}}
#
# RESULTADO ENVIADO PELO SCRIPT: 123.456.789.123 - XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX
#
# HISTÓRICO DE VERSÕES:
#    1.0.0 - VERSÃO INICIAL FUNCIONAL.
#    1.1.0 - ADICIONADA CONSULTA À API IPINFO.IO PARA OBTER A ORGANIZAÇÃO.
# =====================================================================


# DEFINE O PROTOCOLO DE SEGURANÇA TLS 1.2 PARA AS CONEXÕES HTTPS.
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12


# MONTA AUTOMATICAMENTE O CAMINHO COMPLETO DO ARQUIVO SENDRESULT.BAT.
# $ENV:USERPROFILE REPRESENTA A PASTA DO USUÁRIO ATUALMENTE CONECTADO AO WINDOWS.
$SENDRESULT = Join-Path $env:USERPROFILE ".TRIGGERcmdData\SendResult.bat"


# INICIA O BLOCO PRINCIPAL DE TRATAMENTO DE ERROS.
try {

    # ================================================================
    # CONSULTA A API DO MEU IP PARA OBTER O ENDEREÇO IP PÚBLICO.
    # ================================================================
    #
    # -URI:
    #   DEFINE O ENDEREÇO DA API QUE SERÁ CONSULTADA.
    #
    # -TIMEOUTSEC 3:
    #   DEFINE UM LIMITE DE 3 SEGUNDOS PARA A RESPOSTA DA API.
    #
    # -ERRORACTION STOP:
    #   FAZ COM QUE UM ERRO NA CONSULTA SEJA TRATADO PELO CATCH.
    $RESPOSTA_MEUIP = Invoke-RestMethod -Uri "https://meuip.com/api/meuip.php" -TimeoutSec 3 -ErrorAction Stop


    # CONVERTE A RESPOSTA RECEBIDA DA API PARA TEXTO.
    #
    # OUT-STRING:
    #   CONVERTE O CONTEÚDO RETORNADO PARA UMA STRING.
    #
    # TRIM():
    #   REMOVE ESPAÇOS E QUEBRAS DE LINHA NO INÍCIO OU NO FINAL.
    $IP_PUBLICO = ($RESPOSTA_MEUIP | Out-String).Trim()


    # ================================================================
    # VERIFICA SE A RESPOSTA POSSUI O FORMATO DE UM ENDEREÇO IPV4.
    # ================================================================
    #
    # A EXPRESSÃO REGULAR VERIFICA SE EXISTEM QUATRO GRUPOS NUMÉRICOS
    # SEPARADOS POR PONTOS.
    #
    # EXEMPLO DE FORMATO ESPERADO: 123.456.789.123
    if ($IP_PUBLICO -match '^\d{1,3}(\.\d{1,3}){3}$') {


        # ============================================================
        # CONSULTA A API DO IPINFO.IO.
        # ============================================================
        #
        # O IP OBTIDO ATRAVÉS DO MEU IP É INFORMADO DIRETAMENTE NA URL.
        #
        # EXEMPLO:
        #    https://ipinfo.io/123.456.789.123
        #
        # O OBJETIVO É OBTER AS INFORMAÇÕES REFERENTES EXATAMENTE AO
        # ENDEREÇO IP QUE FOI RETORNADO PELA API DO MEU IP.
        try {

            $RESPOSTA_IPINFO = Invoke-RestMethod -Uri "https://ipinfo.io/$IP_PUBLICO" -TimeoutSec 3 -ErrorAction Stop


            # O PARÂMETRO "org" DA API IPINFO RETORNA, POR EXEMPLO:
            #
            #    AS123456 XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX
            #
            # REMOVE:
            #    AS123456
            #
            # E MANTÉM:
            #    XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX
            $ORGANIZACAO = $RESPOSTA_IPINFO.org -replace '^AS\d+\s+', ''


            # MONTA O RESULTADO FINAL QUE SERÁ ENVIADO AO TRIGGERCMD.
            #
            # EXEMPLO:
            #    123.456.789.123 - XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX
            $RESULTADO_MEUIP = "$IP_PUBLICO - $ORGANIZACAO"
        }


        # CASO A API IPINFO.IO NÃO RESPONDA OU OCORRA ALGUM ERRO,
        # O SCRIPT MANTÉM O IP OBTIDO ATRAVÉS DA API DO MEU IP.
        catch {

            # ENVIA SOMENTE O ENDEREÇO IP COMO RESULTADO.
            $RESULTADO_MEUIP = "$IP_PUBLICO"
        }
    }


    # ================================================================
    # CASO A RESPOSTA DA API DO MEU IP NÃO TENHA FORMATO DE IPV4.
    # ================================================================
    else {

        # DEFINE UMA MENSAGEM INFORMANDO QUE A RESPOSTA DA API
        # NÃO CORRESPONDEU AO FORMATO ESPERADO.
        $RESULTADO_MEUIP = "A API retornou uma resposta invalida."
    }
}


# ================================================================
# CAPTURA ERROS OCORRIDOS DURANTE A CONSULTA DO MEU IP.
# ================================================================
catch {

    # DEFINE UMA MENSAGEM INFORMANDO QUE NÃO FOI POSSÍVEL
    # CONSULTAR O ENDEREÇO IP PÚBLICO.
    $RESULTADO_MEUIP = "Nao foi possivel consultar o seu IP Publico."
}


# ================================================================
# ENVIA O RESULTADO PARA O TRIGGERCMD.
# ================================================================
#
# $SENDRESULT:
#    CONTÉM O CAMINHO COMPLETO PARA O ARQUIVO SENDRESULT.BAT.
#
# "$RESULTADO_MEUIP":
#    PASSA O RESULTADO COMO ARGUMENTO PARA O ARQUIVO BAT.
#
# EXEMPLO DO VALOR ENVIADO:
#
#    123.456.789.123 - XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX
#
# IMPORTANTE:
#    O SCRIPT NÃO ENVIA A FRASE "SEU IP PÚBLICO É".
#    ESSA FRASE DEVE SER CONFIGURADA NO TRIGGERCMD EM VOICE/MCP REPLY".
& $SENDRESULT "$RESULTADO_MEUIP"


# ENCERRA O SCRIPT POWERSHELL INFORMANDO QUE A EXECUÇÃO FOI
# CONCLUÍDA NORMALMENTE.
#
# O CÓDIGO 0 INDICA EXECUÇÃO CONCLUÍDA COM SUCESSO.
exit 0

5 - ENTENDENDO O SCRIPT:

5.1 - Configuração do TLS

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Essa configuração força o uso do TLS 1.2 para as conexões HTTPS realizadas pelo PowerShell.

6 - LOCALIZAÇÃO DO SendResult.bat:

O script identifica automaticamente o arquivo SendResult.bat utilizando:

$SENDRESULT = Join-Path $env:USERPROFILE ".TRIGGERcmdData\SendResult.bat"

Isso evita colocar um caminho absoluto como:

C:\Users\NomeDoUsuario\...

Dessa forma, o script pode ser utilizado por diferentes usuários do Windows.

7 - CONSULTANDO O IP PÚBLICO - MEU IP:

A primeira API utilizada é:

https://meuip.com/api/meuip.php

O PowerShell executa:

$RESPOSTA_MEUIP = Invoke-RestMethod -Uri "https://meuip.com/api/meuip.php" -TimeoutSec 3 -ErrorAction Stop

Depois, o resultado é armazenado em:

$IP_PUBLICO

8 - VALIDANDO O ENDEREÇO IP:

O script verifica se a resposta possui o formato básico de um endereço IPv4:

if ($IP_PUBLICO -match '^\d{1,3}(\.\d{1,3}){3}$')

Se a resposta for considerada válida, o script continua para a consulta no IPinfo.io.

9 - CONSULTANDO A ORGANIZAÇÂO - IPINFO.IO:

Depois de obter o endereço IP, o script consulta a segunda API:

https://ipinfo.io/$IP_PUBLICO

Por exemplo:

https://ipinfo.io/123.456.789.123

O resultado é armazenado em:

$RESPOSTA_IPINFO

10 - OBTENDO A ORGANIZAÇÃO - ISP:

O campo utilizado pelo script é:

org

O IPinfo.io pode retornar algo semelhante a:

AS123456 XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX

O script remove automaticamente o ASN:

$ORGANIZACAO = $RESPOSTA_IPINFO.org -replace '^AS\d+\s+', ''

O resultado passa a ser:

O NOME DO SEU ASN OU PROVEDOR DE INTERNET

11 - MONTANDO O RESULTADO FINAL:

O script combina o endereço IP e a organização:

$RESULTADO_MEUIP = "$IP_PUBLICO - $ORGANIZACAO"

Resultado:

123.456.789.123 - XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX

12 - TRATAMENTO DE FALHA DO IPINFO.IO:

Uma característica importante desta implementação é que o IPinfo.io possui seu próprio try/catch.

Isso significa que, se o IPinfo.io estiver indisponível, o script ainda poderá retornar o IP público obtido pelo MEU IP.

Nesse caso:

123.456.789.123

será enviado ao TRIGGERcmd.

Assim, uma falha secundária não impede completamente a execução do comando.

13 - ENVIANDO O RESULTADO PARA O TRIGGERcmd:

Depois de processar as informações, o script executa:

& $SENDRESULT "$RESULTADO_MEUIP"

Isso chama o:

SendResult.bat

e envia o conteúdo de $RESULTADO_MEUIP para o TRIGGERcmd.

14 - CONFIGURANDO O COMANDO NO TRIGGERcmd:

No TRIGGERcmd, crie ou edite um comando para executar o PowerShell.

O comando deverá executar o arquivo .ps1.

Por exemplo:

powershell.exe -ExecutionPolicy Bypass -File "C:\SCRIPTS\IP_PUBLICO.ps1"

Substitua o caminho pelo local onde você salvou o script.

15 - CONFIGURANDO O VOICE/MCP REPLY:

Para utilizar o resultado com Alexa, configure o campo:

Voice/MCP Reply

Utilize:

Seu IP Público é: {{result}}

O {{result}} será substituído automaticamente pelo resultado enviado pelo script.

Por exemplo, se o PowerShell enviar:

123.456.789.123 - XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX

a resposta poderá ser:

Seu IP Público é: 123.456.789.123 - XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX

16 - POR QUE A FRASE NÃO É ENVIADA PELO POWERSHELL?

Nesta implementação, o PowerShell envia somente os dados:

IP - ORGANIZAÇÃO

A frase em português é configurada diretamente no TRIGGERcmd.

Isso possui uma vantagem importante: evita problemas de codificação de caracteres entre PowerShell, Windows, SendResult.bat e a API.

Por exemplo, caracteres como:

A: á, à, â, ã, Á, À, Â, Ã
E: é, ê, É, Ê
I: í, Í
O: ó, ô, õ, Ó, Ô, Õ
U: ú, Ú
Cedilha: ç, Ç (usado com a letra c)
Trema: ¨

podem sofrer alterações dependendo da codificação utilizada durante o processamento.

Por isso, a solução separa:

DADOS:

123.456.789.123 - XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX

RESPOSTA DE VOZ:

Seu IP Público é: {{result}}

17 - TESTANDO:

Antes de utilizar Alexa, recomenda-se testar o script diretamente no Windows.

Execute:

powershell.exe -ExecutionPolicy Bypass -File "C:\SCRIPTS\IP_PUBLICO.ps1"

Depois, verifique o resultado no TRIGGERcmd.

O resultado esperado será semelhante a:

123.456.789.123 - XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX

18 - TESTANDO COM ALEXA:

Depois que o comando estiver funcionando no TRIGGERcmd, execute o comando através da integração de voz configurada.

A Alexa deverá utilizar o conteúdo de:

{{result}}

para gerar a resposta.

Exemplo:

Seu IP Público é: 123.456.789.123 - XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX

19 - ESTRUTURA FINAL:

A solução completa fica organizada da seguinte maneira:

TRIGGERcmd
│
├── Trigger:
│       └── IP Público
│
├── Command:
│       └── powershell -ExecutionPolicy Bypass -File "C:\SCRIPTS\IP_PUBLICO.ps1"
│
├── Ground:
│       └── Foreground
│
├── Voice:
│       └── Rede
│
├── Voice/MCP Reply:
│       └── Seu IP Público é: {{result}}
│
├── MCP Tool Description:
│       └── Consulta o IP Público
│
├── Permitir Parâmetros:
│       └── False
│
└── Computador Windows
        │
        └── PowerShell
                │
                ├── MEU IP API
                │       └── IP Público
                │
                ├── IPinfo.io API
                │       └── Organização
                │
                └── SendResult.bat
                        └── TRIGGERcmd Result

20 - CRIAR ROTINA PERSONALIZADA NA ALEXA:

A rotina completa fica organizada da seguinte maneira:

ROTINA
│
├── Nome:
│     └── Abrir Rede
│
├── Quando:
│     └── Voz
│           ├── Abrir Rede
│           └── Qual é minha Rede
│
└── Alexa Vai:
      └── Personalizar
            └── pergunte à Execute Comando para executar Rede

Para seu Dispositivo Alexa, pergunte à ela: "Alexa, abrir Rede"

21 - CHECAR A EXECUÇÂO EM SUA LISTA DE TRIGGERS:

A execução do comando de Voz e a execução da Trigger será mostrada em Ver Execuções.

22 - CONSIDERAÇÕES FINAIS:

Esta implementação foi desenvolvida com foco em simplicidade, reutilização e compatibilidade com o ambiente Windows + TRIGGERcmd.

O objetivo não é apenas consultar um endereço IP, mas demonstrar como um script PowerShell pode:

Consumir uma API externa.
Processar uma resposta.
Consumir uma segunda API.
Manipular os dados recebidos.
Tratar falhas de serviços externos.
Enviar o resultado para o TRIGGERcmd.
Utilizar {{result}} em uma resposta de voz.

A estrutura também permite que outras APIs sejam adicionadas futuramente, mantendo o mesmo conceito de integração.

Nota de rodapé

Autor: Igor Neth dos Santos
Alma Mater: UniCesumar - Superior de Tecnologia em Redes de Computadores (2015 - 2018)
Apoio: Edson Alexandre Domingues Moreno - Professor Moreno
País: Brasil
Projeto: Consulta de IP Público - TRIGGERcmd
Versão: 1.1.0

LinkedIn:
https://www.linkedin.com/in/igorneth
https://www.linkedin.com/in/alexandre-moreno-a35b74100

Este projeto foi desenvolvido com o auxílio e orientação do meu Professor, Edson Alexandre Domingues Moreno - Professor Moreno, a quem agradeço pelo apoio técnico e pela contribuição durante o desenvolvimento e testes da solução.

Posts

TRIGGERcmd - Service Status — Global Monitoring, High Availability, and Reliability

1. Domain and Infrastructure:

2. Project Goals:

3. Platforms and Technologies:

3.1. Uptime Kuma — Open-Source Monitoring Platform

3.2. Cloudflare Tunnel — Secure Application Access

3.3. Globalping — Distributed Monitoring

4. Monitor Organization:

Group 1 — Server

Group 2 — API

Group 3 — ICMP

Group 4 — Resolution

5. Public Access and Compatibility

6. Why would this monitoring be important?

7. Final Thoughts:

TRIGGERcmd - Service Status — Monitoramento Global, Alta Disponibilidade e Confiabilidade

1. Domínio e Infraestrutura:

2. Objetivos do Projeto:

3. Plataformas e Tecnologias Utilizadas:

3.1. Uptime Kuma — Plataforma de Monitoramento (Open Source)

3.2. Cloudflare Tunnel — Acesso Seguro à Aplicação

3.3. Globalping — Monitoramento Distribuído

4. Organização dos Sensores:

Grupo 1 — Server

Grupo 2 — API

Grupo 3 — ICMP

Grupo 4 — Resolution

5. Acesso Público e Compatibilidade:

6. Por que esse monitoramento seria importante?

7. Considerações finais:

1 - COMO FUNCIONA:

2 - PRÉ-REQUISITOS:

3 - ARQUIVO SendResult.bat:

4 - CRIANDO O SCRIPT POWERSHELL:

5 - ENTENDENDO O SCRIPT:

5.1 - Configuração do TLS

6 - LOCALIZAÇÃO DO SendResult.bat:

7 - CONSULTANDO O IP PÚBLICO - MEU IP:

8 - VALIDANDO O ENDEREÇO IP:

9 - CONSULTANDO A ORGANIZAÇÂO - IPINFO.IO:

10 - OBTENDO A ORGANIZAÇÃO - ISP:

11 - MONTANDO O RESULTADO FINAL:

12 - TRATAMENTO DE FALHA DO IPINFO.IO:

13 - ENVIANDO O RESULTADO PARA O TRIGGERcmd:

14 - CONFIGURANDO O COMANDO NO TRIGGERcmd:

15 - CONFIGURANDO O VOICE/MCP REPLY:

16 - POR QUE A FRASE NÃO É ENVIADA PELO POWERSHELL?

17 - TESTANDO:

18 - TESTANDO COM ALEXA:

19 - ESTRUTURA FINAL:

20 - CRIAR ROTINA PERSONALIZADA NA ALEXA:

21 - CHECAR A EXECUÇÂO EM SUA LISTA DE TRIGGERS:

22 - CONSIDERAÇÕES FINAIS:

Nota de rodapé