dash ruft smartHome

Wednesday, 7. March 2018

Und wie ?

das Teil hat eine recht kleine Batterie und Amazon hat die Button deshalb so ausgelegt, dass sie nur nach dem Knopfdruck kurz booten, ins WLAN gehen, ihre Message abgeben und sich dann wieder runterfahren.
Bei der Ersteinrichtung lernt das dash die SSID und das Passwort für das Wlan, aber die IP holt es sich jedesmal vom dhcpd.
Und dabei kann man den Button erwischen.

Im Prinzip konfigurierst du dir den dash erst mal so, wie Amazon vorgibt. (Wähle dir einen dash, der Bestellungen ~5€ von Produkten erlaubt, die du gebrauchen kannst. Du bekommst nicht 4,99 erstattet sondern auf die erste Bestellung bis zu 4,99€ Rabatt. Zu billig darf das Produkt also nicht sein) 
Und ja, einmal bestellen, um den Rabatt zu kassieren. (Persönlich finde ich, dass A. da ausreichend 'Ne-doch-nich'-Schwellen und Kindersicherungen eingebaut hat. )
Dann setzt du den Dash zurück und gehst den Weg noch einmal, aber den letzten Schritt: Produktwahl, lässt du aus. Schon hast du einen Dash, der funktioniert, aber nicht richtig bestellen kann. An sich genau, was wir wollen. A. will das nicht und schickt pro Klick auf den dash eine Mail...

Jetzt ist es an der Zeit, in /var/log/daemon.log (oder wo bei dir der dhcpd seine logs ablegt) nachzuschauen, welche MAC der dash benutzt. Und für die MAC legt du eine feste IP an. 
Mit WireShark kannst du nun zuschauen, was der dash mit A. so zu besprechen hat. Und dann machst du in der firewall genau diese Verbindung zu. Aus ist's mit den Mails.

So, jetzt fehlt eigentlich nur noch die Hauptsache. Etwas muss im WLAN die Fühler hochhalten und die dhcp-requests des Dash erschnüffeln. python mit scapy können sowas. Wie genau, tja, da gibt es einen Rüstungswettlauf zwischen A. und Technikforschern. Also googeln und durchprobieren. (siehe unten)

Letztlich hast du etwas, das nach ~3 sec einen event auf deinem smarthome*-Bus auslösen kann, dann ~10 Sekunden Unerreichbarkeit (der dash versucht verzweifelt, A. zu erreichen und schmollt anschliessend noch etwas.)

Alles in allem ein konkurrenzlos günstiger Wifi-Switch mit heftiger Latenz.

 Bei mir tut dies:

#!/usr/bin/python
#############################################
from scapy.all import *
import sys, os

def arp_display(pkt):
    if pkt.haslayer(DHCP):

        if pkt[Ether].src == "fc:65:de:bb:xx:yy": 
            os.system('/usr/bin/curl --silent --header "Content-Type: text/plain" --request POST --data "ON" http://192.168.55.44:8080/rest/items/dashConnect_01')

        if pkt[Ether].src == "fc:a6:67:cc:xx:yy": 
            os.system('/usr/bin/curl --silent --header "Content-Type: text/plain" --request POST --data "ON" http://192.168.55.44:8080/rest/items/dashConnect_02')

print sniff(prn=arp_display, store=0,count=0)


und damit das als daemon läuft und auch nach einem Neustart des raspi wieder läuft, habe ich es als einen service bei systemd angelegt:
/lib/systemd/system/dashsniffer.service 



[Unit]                                                                                                                                                                                            
Description=dash dhcp Paket Sniffer                                                                                                                                                              
After=multi-user.target                                                                                                                                                                           
                                                                                                                                                                                                  
[Service]                                                                                                                                                                                         
Type=simple                                                                                                                                                                                       
ExecStart=/usr/bin/python /var/local/scripts/dash/dashSniffer.py                                                                                                                                               
Restart=on-abort                                                                                                                                                                                  

 
[Install]
WantedBy=multi-user.target


dash ruft smartHome

Wednesday, 7. March 2018

Und wie ?

das Teil hat eine recht kleine Batterie und Amazon hat die Button deshalb so ausgelegt, dass sie nur nach dem Knopfdruck kurz booten, ins WLAN gehen, ihre Message abgeben und sich dann wieder runterfahren.
Bei der Ersteinrichtung lernt das dash die SSID und das Passwort für das Wlan, aber die IP holt es sich jedesmal vom dhcpd.
Und dabei kann man den Button erwischen.

Im Prinzip konfigurierst du dir den dash erst mal so, wie Amazon vorgibt. (Wähle dir einen dash, der Bestellungen ~5€ von Produkten erlaubt, die du gebrauchen kannst. Du bekommst nicht 4,99 erstattet sondern auf die erste Bestellung bis zu 4,99€ Rabatt. Zu billig darf das Produkt also nicht sein) 
Und ja, einmal bestellen, um den Rabatt zu kassieren. (Persönlich finde ich, dass A. da ausreichend 'Ne-doch-nich'-Schwellen und Kindersicherungen eingebaut hat. )
Dann setzt du den Dash zurück und gehst den Weg noch einmal, aber den letzten Schritt: Produktwahl, lässt du aus. Schon hast du einen Dash, der funktioniert, aber nicht richtig bestellen kann. An sich genau, was wir wollen. A. will das nicht und schickt pro Klick auf den dash eine Mail...

Jetzt ist es an der Zeit, in /var/log/daemon.log (oder wo bei dir der dhcpd seine logs ablegt) nachzuschauen, welche MAC der dash benutzt. Und für die MAC legt du eine feste IP an. 
Mit WireShark kannst du nun zuschauen, was der dash mit A. so zu besprechen hat. Und dann machst du in der firewall genau diese Verbindung zu. Aus ist's mit den Mails.

So, jetzt fehlt eigentlich nur noch die Hauptsache. Etwas muss im WLAN die Fühler hochhalten und die dhcp-requests des Dash erschnüffeln. python mit scapy können sowas. Wie genau, tja, da gibt es einen Rüstungswettlauf zwischen A. und Technikforschern. Also googeln und durchprobieren. (siehe unten)

Letztlich hast du etwas, das nach ~3 sec einen event auf deinem smarthome*-Bus auslösen kann, dann ~10 Sekunden Unerreichbarkeit (der dash versucht verzweifelt, A. zu erreichen und schmollt anschliessend noch etwas.)

Alles in allem ein konkurrenzlos günstiger Wifi-Switch mit heftiger Latenz.

 Bei mir tut dies:

#!/usr/bin/python
#############################################
from scapy.all import *
import sys, os

def arp_display(pkt):
    if pkt.haslayer(DHCP):

        if pkt[Ether].src == "fc:65:de:bb:xx:yy": 
            os.system('/usr/bin/curl --silent --header "Content-Type: text/plain" --request POST --data "ON" http://192.168.55.44:8080/rest/items/dashConnect_01')

        if pkt[Ether].src == "fc:a6:67:cc:xx:yy": 
            os.system('/usr/bin/curl --silent --header "Content-Type: text/plain" --request POST --data "ON" http://192.168.55.44:8080/rest/items/dashConnect_02')

print sniff(prn=arp_display, store=0,count=0)


und damit das als daemon läuft und auch nach einem Neustart des raspi wieder läuft, habe ich es als einen service bei systemd angelegt:

/lib/systemd/system/dashsniffer.service 



[Unit]                                                                                                                                                                                            
Description=dash dhcp Paket Sniffer                                                                                                                                                              
After=multi-user.target                                                                                                                                                                           
                                                                                                                                                                                                  
[Service]                                                                                                                                                                                         
Type=simple                                                                                                                                                                                       
ExecStart=/usr/bin/python /var/local/scripts/dash/dashSniffer.py                                                                                                                                               
Restart=on-abort                                                                                                                                                                                  

 
[Install]
WantedBy=multi-user.target


raspberry openHab Links

Wednesday, 24. January 2018

PinOut physical/BCM/WiringPi 

 

AdaFruit DHT temp/humid sensor project

Temperatur- und Luftfeuchtigkeitsmessung mit Sensor DHT22/AM2302 und Raspberry Pi

 

Presence detection by mobile
It’s Android so my first approach would be to set up Tasker to turn ON/OFF an OH Item through the OH REST API when Tasker sees the home wifi.

Kalender einbinden:
Binding-docu

Zeiten und Rythmen, Astro und DayTime

Chromecast Audio bespielen:
https://community.openhab.org/t/starting-a-google-play-music-playlist-on-a-chromecast-audio/38619

433 Mhz Funk für FunkSteckDosen, openhab-Einbindung

Openhab docu:

Sitemaps Items Rules  Rules-Tutorial  Xtend-Docu  community.openhab.org/

Editor: VS Code Tool: CronMaker 

 

 

 

 

updating aur packages with yaourt

Wednesday, 6. December 2017

This is a work in progress for right now I dont seem to know how to do it right.

sudo yaourt -Syu --aur 

searches through my system and upgrades the db and then presents me a list of aur packages that need upgrade and then it works it's way through the list and I need to stay there and check every dialog and when there is a package I do not wish to upgrade I cannot skip it. Sure, there is a dialog asking me if I want to update this package, but if I give it a "no" the entire routine is aborted.

So, in case the package I really want to update happens to be the last in yaourt's list I have to update all of them, including the huge font collection which takes ages to download and build, and including the printer driver which I'd rather not touch at all.

That got me shouting and cursing yesterday cause following the update of the driver for the Brother QL-710w label printer the darn thing wouldnt print any more. CUPS was happy though, preparing the print data, posting them to /var/spool/cups and instantly flag it for completed, no errors.

The package that gave me trouble is  aur.archlinux.org/packages/brother-ql710w/  with the version 1.1.4r0. The prior version, pkgver=1.0.2r0 had installed and worked like a charm.

I spent hours trying to find a reason ar even a hint t what was failing to work but nothing helped until I decided to downgrade to the original version.
Now, with 'official' arch packages this is rather esy, there is a storage of older versions at /var/cache/pacman/pkg and you can take the package from there and downgrade with a pacman -U packageName

 But packages from aur are built when you install them, in /tmp and so they are usually lost when you try to step back. I have learned now that there is an option to change this in the /etc/yaourtrc config file. Next time it will be easier.. But as things were I chose a different path yesterday, I manually downgraded the package when it offers me to edit the build script. Changing the pkgver and the sha256sums was all it took.

One of the things I discovered was a nice feature of the aur git, in my case the url is https://aur.archlinux.org/cgit/aur.git/?h=brother-ql710w

I clicked around and soon had the site show me diffs of the prior and new version. Clearly the package was not at fault for my problems. Or Brother has changed some requirement for the install which the former version did not need and which should be reflected in the new package version - I didn't investigate this.

What I did is, searching on the Brother support site for links to older versions of the driver (none!) and then play around with the new url until I succeeded to get the old versions. Naming conventions are a good thing. Then, after successfully downloading them I took their sha256sums

sha256sum ql710wcupswrapper-1.0.2-0.i386.rpm

and those I pasted into the build script. After hours of fruitless trying I was perplexed to see it work on the first go.

That step wasn't actually necessary, I could have taken the sums from the diff at aur.archlinux.org/cgit/aur.git/diff/PKGBUILD 

 

FireFox Sync Server

Thursday, 30. November 2017

After years of Chromium as my default browser I've moved to give FF a new go after the release of v57 aka Quantum. Mozilla is still more trustworthy than Google and hey, I prefered Netscape over Mosaic once. Part of the shift was trying out FireFox sync. Since I have not much trust in the cloud unless it is my own server this meant installing Firefox Syncserver on my debian server.

I more or less followed the howto from sathya.de/blog/how-tos/setup-your-own-firefox-1-5-sync-server-on-debian-with-apache2-and-mysql/ , there are links to the mozilla docu included on his site. The basic steps are easy to take, with dns.he.net and letsencrypt with dehydrated setup of a new subdomain with a valid SSL-certificate has gone down to a matter of minutes.

Git clone the server, create a db and db-user, config the virtualhost in the web servers configuration, edit the default syncserver.ini, restart the webserver and then tell the clients in about:config which syncserver to use. Pretty basic, but it still has some potential for confusion and took me two runs to get it running.

the supplied syncserver.ini has an entry   public_url = http://localhost:5000/   which appears to suggest that ports should be defined in the server config, client config. But this is not so, in a production environment with https and a web server non ports are given.

I saw 404 errors in the error_log which stemmed from an error with the client config, I had erased the token/ - ppart of the uri. And I experienced a multitude of 500 server errors with traces in the error_log pointing at a line between Public_url = ... and allow_new_users = ...
The first complained the given secret exceeded the maximum length, while it had been created like the comments advise. Later I saw errors from parsing the sqluri. Many visual checks did not find a problem.

What helped me was a set of voodoo measures including: manually retyping the sqluri line  and  inserting a 'dummy = stupid' line supposed to catch any non-visible carried syntactical elements. Other possible sources of problems here include permissions issues and missing execution flag on the wsgi file.

And then, suddenly, it worked.

 

(Seite 1 von 35, insgesamt 171 Einträge) » nächste Seite