script

Doorbell – Homebridge

Ich hab ja den Pi neu aufgesetzt… da wollte ich Homebridge mal wieder testen. Da fiel mir ein, es wäre doch praktisch wenn man einen Live-Stream hätte…
Gesagt, getan.

Hab das Script angepasst, dass der Video Treiber automatisch geladen wird:

# Camera for Homebridge
cmdCamHomebridge='sudo modprobe bcm2835-v4l2'
subprocess.call(cmdCamHomebridge, shell=True)

Ihr müsst auch euren User (pi), zur video Gruppe hinzufügen:

sudo usermod -a -G video pi

In der HomeKit App musste ich dann den Code (gleicher wie Bridge) manuell hinzufügen. Dann erscheint die Kamera. Nun kann ich bequem vom iPhone oder der Apple Watch meine Haustüre betrachten…

Von |2018-02-18T20:39:06+01:002018-02-19|Doorbell, Projekte|

Doorbell – Installation

Ich hatte schon lang auf meiner Todo-Liste, den Rapsberry 1 gegen 3 zu tauschen. Nehme diesen oft zum Testen her und da ist er schon ziemlich langsam. Nun konnte ich den alten nicht mehr im Netzwerk erreichen, aber er klingelte noch fröhlich. Nach dem Austausch musste ich feststellen dass die PV-Anlage die IP Adresse nicht freigegeben hatte… Warum auch immer… 🤦‍♂️

Natürlich hatte ich ein Backup, aber ich wollte den Pi neu einrichten. Clean-Install ist eh meist die bessere Entscheidung. Darum schreib ich hier kurz eine Notiz an mein Zukunfts-Ich, was alles zu tun ist:

  • raspi-config
    • Sprachen einstellen
    • Hostname einstellen
    • Kamera aktivieren
  • Update/Upgrade OS
  • Kamera LED ausschalten
  • VNC installieren
  • Doorbell
    • Python-Script auf den Desktop
    • slacker  mit pip  installieren
    • Autostart des python scriptes: sudo lxterminal -e python Desktop/doorbell/doorbell.py
Von |2018-02-18T20:26:24+01:002018-02-18|Doorbell, Projekte|

Eventlogger Update

Ich hatte ja hier mal einen Eventlogger geschrieben. Diesen habe ich jetzt erweitert. Es werden folgende Eigenschaften gespeichert:

  • Uhrzeit
  • Eventname
  • Eventparameter (falls vorhanden)

Es ist auch eine Blacklist vorhanden, da diese Events immer gefeuert werden bzw. wenn EPLAN im Idle-Modus ist.

using System;
using System.Collections.Generic;
using System.IO;
using Eplan.EplApi.ApplicationFramework;
using Eplan.EplApi.Scripting;
using EventHandler = Eplan.EplApi.ApplicationFramework.EventHandler;

public class EventLogger
{
  EventHandler eventHandler = new EventHandler();

  [DeclareRegister]
  public void Register()
  {
    eventHandler.SetEvent("*");
    EventHandlerNameFunction eventHandlerNameFunction = Event;
    eventHandler.EplanNameEvent += eventHandlerNameFunction;
  }

  [DeclareUnregister]
  public void UnRegister()
  {
    eventHandler.Dispose();
  }

  private void Event(IEventParameter eventParameter, string eventName)
  {
    // Check Blacklist
    List<string> blackList = new List<string>
    {
      "onIdle.Bool.App",
      "onLastIdle.Bool.App",
      "onTimer.UInt.App"
    };

    if (blackList.Contains(eventName))
    {
      return;
    }

    // Get Parameter
    string parameter;
    try
    {
      EventParameterString eventParameterString = new EventParameterString(eventParameter);
      parameter = eventParameterString.String;
    }
    catch
    {
      parameter = string.Empty;
    }

    // Write log
    FileInfo fileInfo = new FileInfo(@"C:\Test\Events.txt");
    using (StreamWriter streamWriter = fileInfo.AppendText())
    {
      string line = string.Format("{1}{0}{2}{0}{3}",
        "\t",
        DateTime.Now.ToString("HH:mm:ss"),
        eventName,
        parameter);

      streamWriter.WriteLine(line);
    }
  }
}

 

Von |2018-02-16T09:15:24+01:002018-02-16|EPLAN, EPLAN-Scripts|

Script Debugging: Debugger.IsAttached

Ich hatte hier mal beschrieben wie man den Debugger automatisch anhält… Leider zeigt EPLAN einen Fehler wenn kein Visual Studio dran hängt.
Es geht wie immer besser… Nutzt das hier, dann hält Visual Studio nur an wenn die Einstellung für das Debugging aktiv ist und Visual Studio an EPLAN.exe hängt:

if (Debugger.IsAttached)
{
  Debugger.Break(); 
}

Das kann man sich auch schön verpacken und wie folgt nutzen:

using System.Diagnostics;
using System.Windows.Forms;
using Eplan.EplApi.Scripting;
using Action = System.Action;

public class Test
{
  [Start]
  public void Function()
  {
    Debug(Debugger.Break);

    Debug(()=> MessageBox.Show("Hallo"));

    Debug(() =>
    {
      MessageBox.Show("Hallo");
    });
  }

  private void Debug(Action action)
  {
    if (Debugger.IsAttached)
    {
      action.Invoke();
    }
  }
}

Der Debugger wird nur angehalten wenn Visual Studio dran hängt. Auch die MessageBoxen werden nur angezeigt wenn das der Fall ist. Man kann mit der dritten Varianten auch mehrere Zeilen Code ausführen. Ist zwar nur syntaktischer Zucker, aber denke wird bei mir Anwendung finden.

Von |2018-01-26T15:08:40+01:002018-01-26|EPLAN, EPLAN-Scripts|

LockingVector

Jeder der in der EPLAN API programmiert, kennt die Aufwände beim Locking. Es ist mir nicht immer ganz klar wann was zu verwenden ist. LockingVector sollte nur in Ausnahmefällen verwendet werden, es kann zu unschönen Verhalten kommen. Auch so in der API-Hilfe beschrieben.

Der LockingVector hebelt das Locking komplett aus und die API verhält sich ähnlich wie die Oberfläche. Hört sich gut an, aber wie gesagt für mich nur mit Vorsicht zu genießen.

Dennoch gibt es für mich einen Anwendungsfall: Interne EPLAN Action im API ausführen… Ja manchmal muss man das. Hatte mit Auswertungen aktualisieren den Fall:

LockingVector lockingVector = new LockingVector();
int manualLockStateId = lockingVector.PauseManualLock();

new CommandLineInterpreter().Execute("XFgUpdateEvaluationAction");

lockingVector.ResumeManualLock(manualLockStateId);

Wichtig ist dass ResumeManualLock()  nicht vergessen wird… Ich hab mir das mal in ein Using gepackt, das sich um alles kümmert und auch die Klasse auf GitHub bereitgestellt:

using (new LockingUtility.SeplaLockingVector())
{
  new CommandLineInterpreter().Execute("XFgUpdateEvaluationAction");
}
Von |2018-01-26T14:43:53+01:002018-01-24|EPLAN, EPLAN-API|
Nach oben