Medidor de temperatura casero

Dado que tengo unos cuantos arduino pro micro que he usado para otras cosas, creí bastante conveniente diseñarle una placa para poder ponerle un display oled de 0,96 pulgadas (ssd1306 que ya utilicé en otras entradas) para poder hacer proyectos rápido (en principio pensando en conectarlo a un ordenador y que actúe como teclado, ratón y/o puerto serie). El esquema es el siguiente:

Y la placa resultante quedó así:

Podéis encontrar el proyecto, por si queréis mejorarlo en https://easyeda.com/biblioeteca/promicro-oled

El caso es que, lo primero que se me ocurrió para probarlo, una vez recibidas las placas, fue utilizar otro componente que tenía desde hace tiempo (un sensor de temperatura) y convertirlo en un termómetro… Una pena que no pensara en ello al hacer la placa, por lo que tendré que hacer alguna soldadura de más para conectar el sensor. En concreto quedaría así:

Que visto después de aplicar el soldador se vería así (he aprovechado las pistas de GND y VCC que llegaban al display):

Visto por el otro lado:

La parte de programar la temperatura es un poco más «liosa», básicamente habría que leer la hoja de especificaciones del termistor y resolver la ecuación de Steinhart-hart.

En mi caso, con el valor de 10KOhm en la resistencia y el modelo de termistor que tenía (aquí su hoja de especificaciones) el código resultante para leer la temperatura quedó así:

const int Rc = 10000; //valor de la resistencia
const int Vcc = 5;
const int SensorPIN = A0;
 
float A = 1.11492089e-3;
float B = 2.372075385e-4;
float C = 6.954079529e-8;
 
float K = 2.5; //factor de disipacion en mW/C

void loop() {
  float raw = analogRead(SensorPIN);
  float V =  raw / 1024 * Vcc;
  float R = (Rc * V ) / (Vcc - V);
  float logR  = log(R);
  float R_th = 1.0 / (A + B * logR + C * logR * logR * logR );
  float kelvin = R_th - V*V/(K * R)*1000;
  float celsius = kelvin - 273.15;
  delay(2000);
  // Imprimir la temperatura...
}

Para sacar en el display la temperatura he utilizado la librería Adafruit_SSD1306 que depende de Adafruit_GFX y permite hacer bastantes cosas… Eso sí, dado que mi arduino era lento (estoy usando el de 3.3v) he tenido que inicializar el display cambiando la velocidad del I2C a 400Mhz para que no se note demasiado lag (este display hay que limpiar la zona en la que escribes antes y eso quita ciclos).

Finalmente, una vez probado que funciona, mi intención es hacerlo portable, por lo que le he añadido una pila de 6v conectada a los pines «raw» y «gnd» (el pro micro tiene una entrada regulada en el pin raw) y le he montado una carcasa… Quedando de esta manera (si queréis más detalles me los pedís):

Probando cosillas con arduino beetle

Lo que veis en la foto es un arduino beeetle, bueno, realmente es una placa pro micro con menos pines de los que debería y un conector directo a usb… Como véis es muy pequeño y podéis encontrarlo por un precio bastante económico, aquí, por ejemplo.

Yo ya había utilizado antes el arduino pro micro (leonardo compatible) para simular un teclado en otro proyecto, por lo que sabía que podría utilizar este también para algo similar. Dado su tamaño y lo fácil que se camufla como un «pincho» usb podría pasar desapercibido a la vista… Así que me decidí a ir un pasito más y añadirle un poco más de hardware para controlarlo. Qué mejor que ponerle un botón para indicarle cuando quiero que «teclee algo»… Para ello me aprovecho de que los pines digitales pueden actuar como pull-up y solo tenía que conectar el interruptor entre un pin digital y tierra. En mi caso lo conecté entre el D9 y GND como se puede ver en la foto:

Hice las soldaduras por detrás para proteger un poco más los componentes, pero podría ponerse por delante teniendo un poco más de cuidado.

Una vez el hardware preparado llega el momento de hacer las cosas interesantes… Tampoco es que vaya a ser muy original, pero aquí os dejo el programa que cargué inicialmente…. Funciona en windows y lo que consigues cuando pulsas el botón es que se te abra el chrome con la página web nomorepass.com… (igual sirve como propaganda y todo).

#include "Keyboard.h"
const int buttonPin = 9;

void setup() {
  pinMode(buttonPin, INPUT_PULLUP);
  Keyboard.begin();
}

void loop() {
  while (digitalRead(buttonPin) == HIGH) {
    delay(200);
  }
  delay(100);
  Keyboard.press(KEY_LEFT_GUI);
  Keyboard.press('r');
  Keyboard.releaseAll();
  delay(500);
  Keyboard.print("chrome https>&&nomorepass.com");
  Keyboard.write(KEY_RETURN);
  delay(500);
}

Básicamente lo único que hace es esperar a que el estado del pin al que está conectado el botón pase de alto a bajo (esto es así por la configuración INPUT_PULLUP) y cuando cambia, señal de que hemos pulsado el botón, lo que hace es enviar un COMMAND+r que abre el diálogo de ejecutar de windows y luego envía el texto chrome https://nomorepass.com. Como se puede ver he tenido que transliterar los caracteres que en el teclado americano están colocados en otro sitio (un defectillo de la librería de arduino).

Visto que funciona… Pues ya solo queda hacer una cajita e imprimirla en 3d:

He dejado el diseño en thingiverse por lo que podéis aprovecharlo… Mientras, a inventarnos cosas que hacer con el trasto… «No demasiado diabólicas»..

Subir a maven central una librería propia

Ahora que ya acabas de construir una librería interesante en Java, la has hecho pública (en github, por ejemplo) y quieres que todo el mundo la use… Queda una tarea pendiente, subirla a un repositorio maven para ponerla a disposición de los que utilicen este sistema (o gradle, que hoy en día ya son casi todos).

Vamos a verlo con un ejemplo que he subido esta mañana… Hay cosas que todavía no entiendo del todo, pero el resultado ha sido bueno, por lo que, al menos, podremos usar esta receta como guía para próximas veces.

El código que intento subir es una librería simple que tengo alojada en github con su pom.xml básico y que si te descargas el proyecto podrías compilar e instalar en tu maven con mvn install. La dirección es esta:

https://github.com/yoprogramo/nomorepass-java/

Ahora, para que todo el mundo pueda descargárselo como dependencia y no tenga que hacer el mvn install del proyecto, tenemos que subirlo a un repositorio público, podemos ver una guía en esta página: Guide to Public Maven Repositories. Tal como explican en la página, lo más sencillo para publicar en Maven Central es usar el repositorio Sonatype. Dicho y hecho… Lo intentamos por aquí.

Lo primero es crear una cuenta en el Jira de Sonatype aquí. Lo siguiente, y esto es un poco «tricky» es crear un ticket solicitando un nuevo id de grupo en esta dirección. No se puede pedir cualquier id de grupo (en mi caso quería pedir com.nomorepass) y generalmente se pedirá alguna prueba de que el dominio es tuyo. En mi caso este es el ticket que creé: https://issues.sonatype.org/browse/OSSRH-49426, para demostrar que el dominio era mío cambié el DNS e incluí una entrada TXT con el identificador del ticket:

Una vez autorizado (tarda un poco, es un proceso manual) hay que modificar nuestro código y prepararlo para la subida, pero, antes de eso, tenemos que generar nuestras claves gpg para poder firmar el código. eso se hace con este comando:

gpg --gen-key

Una vez generada podremos acceder a la lista de claves con el comando:

gpg --list-keys

Toma nota del id de la clave y recuerda la contraseña que usaste para generarla, porque tendrás que recordarla. Además, tendrás que publicarla en algún servidor de claves públicas para que pueda ser comprobada.

gpg --keyserver hkp://keys.gnupg.net --send-keys <el-id-de-la-clave>

Ahora empezamos a modificar el pom.xml para que cumpla con los requisitos para el repositorio Maven Central. En nuestro caso pusimos esto:

<groupId>com.nomorepass</groupId>
  <artifactId>nomorepass</artifactId>
  <version>1.0</version>
  <packaging>jar</packaging>

  <name>Nomorepass java library</name>
  <description>NoMorePass protocol 2 implemented on Java.</description>
  <url>https://nomorepass.com</url>

  <licenses>
    <license>
      <name>Apache License, Version 2.0</name>
      <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
      <distribution>repo</distribution>
    </license>
  </licenses>

  <developers>
    <developer>
      <name>Jose Antonio Espinosa</name>
      <email>espinosa@yoprogramo.com</email>
      <organization>Nomorepass</organization>
      <organizationUrl>https://nomorepass.com</organizationUrl>
    </developer>
  </developers>

  <scm>
    <connection>scm:git:git://github.com/yoprogramo/nomorepass-java.git</connection>
    <developerConnection>scm:git:ssh://github.com:yoprogramo/nomorepass-java.git</developerConnection>
    <url>https://github.com/yoprogramo/nomorepass-java/tree/master</url>
</scm>

Y, una vez informado de todo esto, hay que incluir los plugins que nos permitirán hacer el despliegue directamente. Yo añadí esto:

<distributionManagement>
    <snapshotRepository>
      <id>ossrh</id>
      <url>https://oss.sonatype.org/content/repositories/snapshots</url>
    </snapshotRepository>
    <repository>
      <id>ossrh</id>
      <url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
    </repository>
</distributionManagement>

Y puse en mi directorio de maven settings.xml los datos de mi usuario

<settings>
  <servers>
    <server>
      <id>ossrh</id>
      <username>xxxxxxxxxx</username>
      <password>xxxxxxxxxx</password>
    </server>
  </servers>
</settings>

Por último, toda la sección de build (que no tenía) la sustituí por esto:

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-gpg-plugin</artifactId>
        <executions>
          <execution>
            <id>sign-artifacts</id>
            <phase>verify</phase>
            <goals>
              <goal>sign</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>org.sonatype.plugins</groupId>
        <artifactId>nexus-staging-maven-plugin</artifactId>
        <version>1.6.7</version>
        <extensions>true</extensions>
        <configuration>
          <serverId>ossrh</serverId>
          <nexusUrl>https://oss.sonatype.org/</nexusUrl>
          <autoReleaseAfterClose>true</autoReleaseAfterClose>
        </configuration>
      </plugin>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-source-plugin</artifactId>
          <version>2.2.1</version>
          <executions>
            <execution>
              <id>attach-sources</id>
              <goals>
                <goal>jar-no-fork</goal>
              </goals>
            </execution>
          </executions>
        </plugin>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-javadoc-plugin</artifactId>
          <version>2.9.1</version>
          <executions>
            <execution>
              <id>attach-javadocs</id>
              <goals>
                <goal>jar</goal>
              </goals>
            </execution>
          </executions>
        </plugin>
    </plugins>
</build>

Y ya, finalmente, pude ejecutar el mágico:

mvn clean deploy

Si todo ha ido bien, el artefacto estará subido a un repositorio que tendremos que promocionar a «Release» para que se sincronice con el repositorio central… Pero al final ya lo tendremos disponible para todo el mundo…

Aquí podéis encontrar lo que acabo de subir: https://search.maven.org/artifact/com.nomorepass/nomorepass/1.0/jar

Protege tu .git

Hasta hace poco en mi empresa utilizábamos subversion como repositorio, no somos un equipo grande y las funcionalidades que nos ofrecía el repositorio eran suficiente para nuestros proyectos.
Recientemente, debido a que un cliente nos ha impuesto utilizar git como repositorio principal y dado que nuestra relación con ellos es muy importante, decidimos mover todos nuestros repositorios a git. Tampoco es que vayamos a utilizar extensivamente las ventajas que nos ofrece, pero si que nos obligaría a funcionar de manera más fluida con una herramienta que vamos a necesitar si-o-si.

El caso es que, en nuestra anterior configuración, utilizábamos subversion para mantener el código de producción de algunas webs y al modificar el repositorio hicimos lo propio con git, teniendo una «feliz transición». El problema vino en que, realmente, no eramos conscientes de las diferencias reales que tenían los dos repositorios y dentro de los directorios servidos junto a la web en cuestión se encontraba el directorio .git.

¿Qué significa esto? Pues ni más ni menos que todo el mundo mundial tiene acceso a tu repositorio local y puede, entre otras cosas, acceder a todo el código de lo que hay allí publicado… Y eso no puede ser. ¿Qué hacemos para evitarlo?

Hay varias formas de hacerlo, dependiendo de si tienes o no un .htaccess en tu web o no y de la configuración de tu servidor, en mi caso la solución que implementamos fue añadir las siguientes líneas al archivo de configuración de cada web:

        <Directory /directorio.de.la.web/.git>
		Options FollowSymLinks
		AllowOverride All
		Require all denied
	</Directory>

Esto indica al servidor que todo lo que hay bajo el directorio .git no está autorizado para ser visto… Reiniciamos el servidor o recargamos la configuración y ya tendremos el problema resuelto.

Y con esto y un bizcocho… Podemos empezar nuestra semana.