TC emulieren

[frank]

hallo martin,

Den 2. Teil werde ich nicht einbauen. Wenn das device eine Antwort anfordert wird diese gesendet. Alles andere sind Verletzungen des Funkprotokols - und das kann nicht die Loesung sein.

nein, das stimmt nicht!

es wird keine antwort "gefordert". das funkprotokoll von cmd58 ist ja gerade für den fall des "nicht antwortens" konzipiert. der tc sendet tapfer nach seinem rythmus cmd58 und reagiert entsprechend der "häufigkeit der empfangenen" antworten. bei unterschiedlicher häufigkeit mit unterschiedlichen aktionen.

es sind ja expliziet massnahmen vorhanden, die darauf aufbauen, dass die erwartung der antworten unter 100% liegt. es beeinflusst den realen tc auch in keinster weise in seiner funktion. im gegenteil ist es ihm völlig egal, ob der vd antwortet oder nicht. er gibt lediglich ab einer "minimalen häufigkeit" eine warnung an den user aus, um nach fehlern zu schauen.

somit wäre die implementation einer "variablen häufigkeit" der antworten unseres virtuellen vd wesentlich näher an der realität, als die von "dir vorgeschriebene 100%-ige" antwort.

auf deine argumentationsweise aufbauend könnte ich dann auch behaupten, dass fhem, wenn es sich als virtueller vd "tarnt" und sein empfangsfenster für den cmd58 regelverletzend "unendlich" weit aufreisst, es sich damit nicht an das funkprotokoll hält.

um eine echte verletzung des funkprotokolls handelt es sich, wenn man "unnötigerweise" den funkverkehr belastet. wir könnten 80% des funkverkehrs einsparen, weil er nicht notwendig ist und es keine regel gibt, dieses nicht zu tun. im gegenteil  ist die reduzierung "unnötigen" funkverkehrs empfehlenswert, vielleicht sogar vorgeschrieben, um den funkverkehr anderer funkteilnehmer nicht unnötigerweise störend zu beeinflussen.

deine argumente hinterlassen bei mir eher den eindruck, dass du dieses feature einfach nur nicht haben willst. warum auch immer. sicherlich nicht wegen einer verletzung des funkprotokolls.

gruss frank

[martinp876]

Hi Frank,

ob ein device eine Antwort sehen will oder nicht legt es im Flag fest,  nicht im Commandtype. Wie oft wiederholt wird ist eine andere Sache.

Gruss Martin

[frank]

hallo martin,

ich habe gerade festgestellt, dass du zwischen v4820 und v4864 eine änderung bei der eingabe von valvaPosTC vorgenommen haben musst. einstellige positionswerte müssen auf einmal mit vorangestellter "0" eigegeben werden, um ausgeführt zu werden. nicht so entscheidend ist die neue form der ausgabe des readings valvePos beim zustand stopped in der darstellung "off %".

somit kommen die befehle des pid20-reglers nicht mehr durch.

muss ich das nun auffangen und entsprechend modifizieren, oder ist das ein versehen?

gruss frank

[martinp876]

Hi Frank,

konkret:
du willst .1 schicken koennen anstatt 0.1?

Gruss Martin

[betateilchen]

ich vermute anhand seiner Beschreibung, er will "1" schicken können anstatt "01" 

[frank]

ich vermute anhand seiner Beschreibung, er will "1" schicken können anstatt "01" 

ganz genau

gruss frank

[martinp876]

alles klar

[frank]

hallo martin,

also, wegen:

Code Auswählen Erweitern

A2 => 10100010 => bit5 = 1 => bidi

fühlst du dich genötigt, alles "stehen und liegen" zu lassen, um ohne rücksicht auf verluste sofort eine antwort "raus zu hauen".

da kann man nicht mit etwas gelassenheit eventuell ausnahmsweise ein momentchen verharren, um dann wohlüberlegt etwas später mit sicherheit auch das richtige zu antworten? 

[martinp876]

Frank,

es gibt ein Protokoll - das besagt, wenn du angesprochen bist und das Gegenüber eine Antwort erwartet antwortet man. So ist das Protokol definiert. man kann nicht warten oder sonst etwas, da ist ein Zeitfenster.
Ich habe erst einmal nicht die Absicht hier solche Verletzungen einzubauen, auch wenn du ausmessen würdest, dass manche devices her keinen Alarm (Empfänger nicht erreichbar) schicken würden.
HM hat das so definiert, die Gesamtfunklast eines Systems kann es also ab (oder HM hat einen eklatanten Designfehler gemacht).
Dass man als Master einen Ventilwert aus lässt ist grenzwertig... aber gut, wenns sein muss - hab ich eingebaut.

Wie viele virtuelle VDs willst du den betreiben?

Gruss Martin

[frank]

hallo martin,

Ich habe erst einmal nicht die Absicht hier solche Verletzungen einzubauen, auch wenn du ausmessen würdest, dass manche devices her keinen Alarm (Empfänger nicht erreichbar) schicken würden.

na dann. 

Dass man als Master einen Ventilwert aus lässt ist grenzwertig... aber gut, wenns sein muss - hab ich eingebaut.

das kann nicht grenzwertig sein, da der tc das selber so macht. sind 2-4 vd mit ihm gepeert, bedient er die vd der reihe nach, und lässt die anderen "verhungern".

aber trotzdem danke dafür. 

Wie viele virtuelle VDs willst du den betreiben?

wahrscheinlich verdoppeln. das sollte von der funklast dann eigentlich reichen.

zur zeit benötige ich halt 62,5% (25 messages pro std und pro tc) meiner funklast nur dafür, die tc zu streicheln, damit sie mich nicht jede stunde anpeepen. ich weiss ja nicht, was im laufe der zeit noch so ins system aufgenommen werden will. hoffentlich müssen dann nicht existentielle messages warten, nur damit diese unnötigen gesendet werden. kann mann da eventuell prioritäten festlegen?

für mein empfinden sind diese messages ansich schon überflüssig. warum peept der tc überhaupt, wenn kein vd mit ihm gepeert ist? fast in jeder situation nervt mich das teil. wenn man was von ihm will, macht er es nicht oder unzuverlässig. wenn man aber nichts mehr von ihm will, dann peept er äusserst zuverlässig. egal.

denn eigentlich müsste doch ein workaround existieren. ich habe gerade mal versucht mit dem attr ignore zu spielen. leider noch kein glück gehabt. aber da scheint noch ein bug zu existieren. setze ich das parentdevice auf ignore, erzeugt die fehlermeldung "device ignored due to attr 'ignore'" 6 einträge im set-menue des channeldevice. jedes wort einen eintrag.

frage: sollte ein "attr <device> ignore 1" grundsätzlich die kommunikation beenden? und mit "0" wieder beginnen?

gruss frank

[frank]

hallo martin,

mein freund ist attr dummy. 

aber auch hier gibt es probleme:
mit "attr dummy 1" kann ich die messages zwar erfolgreich verhindern. doch ein "attr dummy 0" schaltet die antworten nicht wieder ein. erst ein "delete attr dummy" startet das senden der messages wieder.

das ist doch bestimmt nicht so vorgesehen!

gruss frank

[martinp876]

Hi Frank,

zur zeit benötige ich halt 62,5% (25 messages pro std und pro tc) meiner funklast.... kann mann da eventuell prioritäten festlegen?

Prioritäten gibt es nicht - wie sollte das auch gehen - senden oder nicht, was anderes geht nicht. oder du willst Minuten lang warten...

für mein empfinden sind diese messages ansich schon überflüssig. warum peept der tc überhaupt, wenn kein vd mit ihm gepeert ist? fast in jeder situation nervt mich das teil.

ist nun einmal HM konzept - message und ack - das hat nur sinn, wenn auch gemeldet wird. Das mit dem piepen ist eine spezialitaet...


ignore schaltet senden und empfangen aus.
dummy schaltet senden aus - wird auch in fhem.pl genutzt, habe nicht geprüft, was dort abgefragt wird.

Gruss Martin

[frank]

hallo martin,

ich habe jetzt die v4886 eingespielt. aber msgReduce springt nicht an. wir sind immer im normalmodus.

ich habe attr param msgReduce im parentdevice angelegt. im channel geht nicht. ein get param msgReduce ergibt sowohl im parent- als auch im channeldevice undefined.

ein loggen von $hash->{helper}{vd}{msgRed} in den beiden funktionen ergibt immer 0.

dieser elsif-block wird genau einmal beim shutdown & restart durchlaufen, und initialisiert
$hash->{helper}{vd}{msgRed}=1. ich logge am anfang und am ende von elsif. auf dem weg zur funktion CUL_HM_valvePosUpdt bekommt sie den zustand undefiniert (aber wo?), wodurch sie dann natürlich in der funktion auf 0 gesetzt wird.
ich finde keine stelle an der die variable $hash->{helper}{vd}{msgRed} expliziet gelöscht wird!

Code Auswählen Erweitern

    elsif ($md =~ m/^virtual_/){
      if ($cmd eq "set"){
        if ($attrVal eq "noOnOff"){# no action    
        }
        elsif ($attrVal eq "msgReduce"){#set param
          $hash->{helper}{vd}{msgRed}=1;
        }
        else{
          return "attribut param not defined for this entity";
        }
      }
      else{
        delete $hash->{helper}{vd}{msgRed};
      }
    }
    else{
      return "attribut param not defined for this entity";
    }


gruss frank

[martinp876]

schaue ich mir an...

[frank]

eigentlich kann das nur bedeuten das $hash->{helper}{vd}{msgRed} in elsif und funktion nicht das selbe ist!