Pessoal, só para esclarecer: eu sou notificado a respeito de todas as mensagens que são enviadas aqui para este tópico, por isto fico sabendo dessas panes que ocorrem com os Raspberry Pi. No entanto, como não possuo nenhum dispositivo Raspberry Pi, não tenho como fazer nenhum tipo de teste, investigação etc., e daí fico impossibilitado de tentar ajudar e (talvez, quem sabe) conseguir encontrar alguma solução ou paliativo.
O que posso comentar a respeito desse erro é que a palavra
jssc ("biblioteca de comunicação
serial via
Java") refere-se a uma incompatibilidade entre
muitas que existem entre o Raspberry Pi e o SPV. Essa especificamente envolve a arquitetura da JVM (Máquina VIrtual Java) usada pelo Raspberry Pi e a JVM requerida pelo SPV (utilitário SMS Power View). Isso porque o pessoal da Legrand, ao desenvolver o SPV, desenvolveu-o pensando apenas em computadores que usem processadores de arquitetura Intel X86 e X86_64, i.e. não levou em consideração que existem dispositivos que usam processadores de arquitetura
ARM - como é o caso dos Raspberry Pi.
Uma das consequências disso é que algumas bibliotecas usadas pelo SPV são da JVM específica para processadores de arquitetura Intel X86 e X86_64: não funcionam quando o processador é ARM, e portanto não funcionam em Raspberry Pi.
Essa biblioteca
jssc, por exemplo, é uma biblioteca Java de arquitetura
x86 e o arquivo dela fica em
/opt/sms/libs/jssc-2.8.0.jar (isso para quem instalou o SPV conforme o tutorial deste tópico e, por isto, colocou o SPV em
/opt). Isso pode ser verificado por exemplo executando-se um comando como este:
tail /opt/sms/libs/jssc*.jar |awk -F"/" '{print $3}'...que mostra que a biblioteca jssc usada pelo SPV foi escrita para a arquitetura Intel X86 (de 32 bits e de 64 bits).
Um pacote com o
libjssc-java, por exemplo, talvez seja útil para instalar a versão ARM64 dessa biblioteca em um local como
/usr/share/java/jssc-2.8.0.jar, de onde então pode-se criar um link simbólico após se fazer backup da biblioteca original do SPV. Exemplo:
Fazer backup da biblioteca original:
sudo mv /opt/sms/libs/jssc-2.8.0.jar /opt/sms/libs/jssc-2.8.0.jar.bkpCriar um link simbólico com o mesmo nome e caminho da biblioteca original, porém apontando para a biblioteca que foi instalada:
sudo ln -s /usr/share/java/jssc-2.8.0.jar /opt/sms/libs/jssc-2.8.0.jarIsso fará
/opt/sms/libs/jssc-2.8.0.jar apontar para
/usr/share/java/jssc-2.8.0.jar (que será a biblioteca em versão para processador de arquitetura ARM64).
Se isso não funcionar, outra tentativa que pode ser feita (mas que dificilmente vai funcionar) é baixar a
versão multiplataforma da biblioteca jSerialComm, salvá-la numa pasta qualquer e então recriar aquele link simbólico, fazendo o link simbólico
/opt/sms/libs/jssc-2.8.0.jar apontar para o
/caminho/para/o/arquivo/de/biblioteca/jSerialComm-2.9.3.jarMas, se eu tivesse de apostar, eu apostaria que mesmo que esse problema de incompatibilidade da biblioteca
jssc seja resolvido, logo após o solucionamento o SPV passará a mostrar alguma outra mensagem de erro, relacionada a alguma outra biblioteca Java que o SPV utiliza mas não é compatível com a arquitetura de hardware do processador do Raspberry Pi.
Algo que observei ao longo dos anos é que a maioria das "panes" com Raspberry Pi está relacionada à comunicação serial. Como o nobreak fornece dados em formato serial do tipo
RS-232 porém o SPV está configurado para ler dados em formato serial do tipo
USB (a partir de alguma porta USB do computador ao qual o nobreak está conectado), o SPV utiliza um driver "serial RS-232 para serial USB" e um monte de bibliotecas Java que fazem essa "tradução simultânea" entre os dados seriais oriundos do nobreak e os dados USB oriundos do computador, ora convertendo os dados seriais RS-232 do nobreak para o formato serial USB (para o computador "entender o que o nobreak disse"), ora fazendo o caminho inverso, i.e. convertendo os dados seriais USB do computador para o formato serial RS-232 (para o nobreak "entender o que o computador disse").
Se algum dia eu comprar um Raspberry Pi, vou passar a "alimentar" este tópico com soluções que eu acaso descubra. Mas por ora infelizmente só consigo explicar por alto o que parece estar ocorrendo e lhes desejar boa sorte nessa árdua empreitada - principalmente porque a Legrand pelo visto não parece estar preocupada em modernizar o SPV - pelo menos não o suficiente para que ele possa funcionar "nativamente" com processadores de arquitetura ARM.
