Em 1 de agosto de 2010 10:40, Geraldo <jrfontes.listas@yahoo.com.br> escreveu:

Em 29/07/10 11:20, Mr. Adilson Bonan escreveu:
> Cara, olha so, de SP para STO eu chego via SSH, isso nao eh p[roblema...
> Meu problema comeca em STO qdo chego.. pq nao tenho nenhum software para
> falar com o nobreak de la, saca....

Isso eu entendi.
A questão que fica: é possível acessar o nobreak com outro software que
não aquele desenvolvido pelo fabricante? Essas coisas são padronizadas
ou cada fabricante escolhe como acessar seu equipamento?
Ao que parece existem padrões a esse respeito. D~e uma olhada em
http://www.mcsi.re/client-projects.

Primeiro mail que recebo da lista... Olá, pessoal! :)

Sem ter acompanhado a discussão, pode ser que fale alguma besteira, mas... Vejamos.

Se a comunicação com o equipamento é feita via porta serial, é possível desenvolver um cliente. Em verdade, nem é preciso ter um software específico para trocar mensagens. O que é preciso, necessariamente, é conhecer o protocolo de comunicação. Se não tiver acesso ao protocolo, você pode fazer a engenharia reversa. O que pode complicar é se o protocolo trabalhar com caracteres em hexadecimal e máscaras para checksum.

Para fazer alguns testes, é preciso pelo menos conhecer as configurações para a porta. O linux te oferece tudo para a brincadeira. Para essas coisas eu uso o stty.

Digamos que o equipamento funcione com 9600 bps 8N1 e sua porta serial seja /dev/ttyS0. Eis a linha de comando para configurar sua porta na sessão (pode colocar no rc.local, por exemplo):

stty -F /dev/ttyS0 speed 9600 raw cs8 -parity

Se estiver configurando um shell script, por exemplo, pode controlar o fluxo desta forma:
stty -F /dev/ttyS0 speed 9600 raw cs8 -parity >/dev/null 2>&1 || ERRO "porta serial não disponível ($?)"

Isso vai configurar a porta ou retornar um código de erro.

E como comunicar-se com a porta?

Basta usar echo e cat :)

cat /dev/ttyS0 para "escutar" a porta. Pode usar um loop indefinidamente, para criar um daemon. No mais, como já citei, é preciso conhecer o protocolo para entender as strings de retorno do equipamento. Com sorte, é tudo ASCII, mas se o protocolo falar em hexadecimal, pode fazer um pipe com o hexdump. No seu caso, provavelmente você não vai precisar escrever nada pra ele, pois o interessante é apenas o monitoramento.