Wann gibt es mal wieder eine neue Version?

Siutsch
Beiträge: 243
Registriert: Mo 26. Sep 2016, 13:41

Sa 6. Apr 2019, 14:19

Jahudi hat geschrieben:
Fr 5. Apr 2019, 22:24
Siutsch hat geschrieben:
Fr 5. Apr 2019, 22:00
...
Ne Info, was ggf. noch auf der Pipeline ist und auf was wir uns noch freuen können wäre auch mal ganz nett!
Echt jetzt...?

JbMedia hat gerade erst einen raus gehauen, und hier wird schon das nächste Changelog gefordert ?

Nicht wirklich dein Ernst, oder...? :shock: :roll:
Doch, das ist mein Ernst!

Und "gefordert" habe ich gar nichts, ich schrieb "... wäre auch mal ganz nett".

Da Du ja auch schon lange im Forum unterwegs bist, sollte Dir auch längst aufgefallen sein, dass sich JBMedia mit derlei Infos und auch der Beantwortung direkter Fragen leider recht schwer tut.

Andere Hersteller können sowas übrigens, da gibt es "Milestones" oder was ähnliches und hier und da mal ne Info, was noch so geplant ist oder an was man vielleicht gerade noch arbeitet, schadet ja nun wirklich nicht.
Und auch die Frage / Bitte, warum man als User (der mit dem LM vielleicht mehr macht, als der Durchschnitt) hierbei nicht auch helfen kann (Betatests oder sowas) blieb unbeantwortet.
Wieder eine neue Version ohne vorherige Tests und direkt vor dem WE.
Das hatten wir doch schon ein paar mal, hat selten funktioniert.


Und "Ja", natürlich freue ich mich auf eine neue Version, warte aber auch schon lange auf Dinge, die vielleicht umsetzbar wären, höre da aber nichts mehr von.

Nun warte ich aber erst mal den Changelog von Montag ab und dann schauen wir weiter.
Heiko
Beiträge: 711
Registriert: Sa 20. Feb 2016, 21:16
Wohnort: Dortmund

Sa 6. Apr 2019, 14:59

korken hat geschrieben:
Sa 6. Apr 2019, 13:52
Heiko hat geschrieben:
Sa 6. Apr 2019, 12:55

Irgendwie muß ja IH die Aktoren aus dem Air auslesen, leider werden bei IH eben nicht alle " Aktoren / Sensoren" gefunden.
Genau IH muss die Sensoren auslesen. Und wer ändert die Imperihome App? jbmedia? Wohl eher nicht.
Es gab aber eine Änderung beim Air, und nicht bei IH !
Und vorher funktionierte es !

(Ich selbst habe es noch nicht ausprobiert, ich warte immer erst bis die Betatester alle Probleme gefunden haben ;) )

Wenn das nun nicht mehr funktioniert wird IH immer wertloser für IH Nutzer.
Ich kann mir leider kein eigenes Dashboard programmieren, deshalb greife ich auf IH zurück.
IH hatte ich schon vor dem Airkauf runtergeladen um zu sehen was man damit machen kann.

Ich würde es deshalb sehr begrüßen, wenn in dieser Richtung auch mal etwas passieren würde...
.... und ich denke , ich stehe damit nicht alleine da.
BG

Heiko
Simon
Beiträge: 976
Registriert: Sa 19. Mär 2016, 20:03

Sa 6. Apr 2019, 15:56

korken hat geschrieben:
Sa 6. Apr 2019, 13:49
Imperihome ist eine Drittanbieter App die auf den Lightmanager zugreift. Wenn am Lightmanager etwas geändert wird muss der App Hersteller eben Anpassungen vornehmen.
Wenn jetzt der bisher angezeigte Interne Sensor nicht mehr angezeigt wird, dann kann natürlich ein Fehler im LM vorliegen, muss aber nicht, wenn sich der Zugriff darauf geändert hat.
Aber wenn jbmedia neue Sensoren hinzufügt, in diesem Fall die "neuen" Funksensoren, dann kann doch jbmedia keine Änderungen in Imperihome vornehmen.

Wenn z.B von Philips für Hue neue Funktionen bereit gestellt werden muss doch auch jeder Drittappanbieter die Anpassungen in seiner App vornehmen. Wie sollte Philips das bewerkstelligen?
Das ist Quatsch.
Es gibt eine API dazu, DIE ist für die Übermittlung der Daten zuständig. Demzufolge ist die Frage, WER hat die API dazu programmiert!
Da IH durch diese API Dinge an IH weiterleitet, welche vorher funktioniert haben und jetzt nicht, stellt sich die Frage: WARUM geht dieses nun nicht mehr und WARUM werden die anderen Sensoren nicht so wie der interne Air-Sensor seitens JBMedia behandelt, denn DER wurde! ja korrekt erkannt seitens IH. Seit jeher wird gewünscht, dass die Temp.sensoren genau SO gestaltet werden so dass sie in IH auftauchen.
Nein, man hat ja mit Alexa zu tun gehabt..... fest steht. Aktoren und der interne Sensor wurden durch die API korrekt nach IH weitergereicht, warum nun der int. Sensor nicht mehr, die anderen Aktoren und Szenen dennoch?

Imperihome ist ein DRITTANBIETER der via API Daten heranzieht. Daher ist dieses im Normalfall lediglich eine Sammel-App die ähnlich wie andere Programme / Apps funktioniert. Woher sollte IH die Intelligenz besitzen auf FREMDDATEN anderer Hersteller zugreifen zu können?
Heisst, wird was an der API geändert oder die Weitergabe zur API geändert, dann kann IH logischerweise keine Daten mehr korrekt darstellen...

Die Hues gehen auch via IH und warum? Weil IH lediglich das Hue-System einbindet, mehr nicht! Ändert Philips hier was, dann bekommt IH das logischerweise über die Schnittstelle weitergereicht... So ähnlich ist es mit dem VERA-System und dem Logi-System. Imperihome hat keine / kaum eine eigene Logik, so dass sie immer auf die Infos der Anbieter angewiesen ist. Und somit ist es keine insellösung, da sie als Sammlung diverser API's und Schnittstellen vieles bereitstellen kann....
korken
Beiträge: 153
Registriert: Mi 24. Feb 2016, 18:40

Sa 6. Apr 2019, 16:59

Die Abfrage der API (Schnittstelle) muss aber durch Imperihome passieren. Der LM stellt diese zur Verfügung.
Auch eine API kann sich ändern, diese Änderungen muss dann derjenige bei sich implementieren der die API abfragt.
Vielleicht ein anderes Beispiel.
Eure Stadt baut neue Straßen (hinzufügen von neuen Temp.Sensoren), dann wird nicht die Stadt eure Navigationsgeräte auf den neuesten Stand bringen sondern die Hersteller der Navi Apps.
Heiko
Beiträge: 711
Registriert: Sa 20. Feb 2016, 21:16
Wohnort: Dortmund

Sa 6. Apr 2019, 17:25

Wenn deine Straßen aber keine ein und Ausfahrten haben, sondern nur intern verbunden sind, kann der navihersteller diese zwar einbauen, es füht aber kein weg dahin oder heraus.
Somit ist es nicht möglich dahin zu kommen.
BG

Heiko
Simon
Beiträge: 976
Registriert: Sa 19. Mär 2016, 20:03

Sa 6. Apr 2019, 17:55

korken hat geschrieben:
Sa 6. Apr 2019, 16:59
Die Abfrage der API (Schnittstelle) muss aber durch Imperihome passieren. Der LM stellt diese zur Verfügung.
Auch eine API kann sich ändern, diese Änderungen muss dann derjenige bei sich implementieren der die API abfragt.
Vielleicht ein anderes Beispiel.
Eure Stadt baut neue Straßen (hinzufügen von neuen Temp.Sensoren), dann wird nicht die Stadt eure Navigationsgeräte auf den neuesten Stand bringen sondern die Hersteller der Navi Apps.
Wenn JBMedia die API zur Verfügung stellt, dann ist logischerweise JBMedia für die Programmierung und Korrektheit dieser verantwortlich. Da kannst Du nicht die 3rd party Firma haftbar für machen.... werden Dinge anders gehandhabt, dann sollte die API so angepasst werden, dass eine 3rd party SW Dinge als Aktoren / Sensoren z.B. problemlos erkennt. Das heisst, der Aktor muss als solches erkennbar sein und gekennzeichnet werden, der Sensor ebenso. IH wird sicherlich lediglich abfragen "Aktor" oder "Sensor" und bietet dann dazu entsprechende Widgets an... alles andere an Logik geht über die API direkt an den Anbieter der Aktoren / Sensoren.

Dein Strassenvergleich hinkt... ;)
Weil dafür diverse Firmen miteinander kombiniert werden müssen....
Wenn der Apfel eine falsche Navi-SW baut, welche eine Strasse anstatt eine Klippe erkennt, dann ist da nicht die Stadt für verantwortlich sondern der Hersteller der dubiosen Navi-SW!

Ein schönes Beispiel ist Z-Wave. Dort wurden minimale Standards vereinbart, damit die devices generell funktionieren...
Eine Besonderheit von Z-Wave ist die Vereinheitlichung der Anwenderebene, um die Interoperabilität von Geräten unterschiedlicher Hersteller zu gewährleisten. Z-Wave-Geräte werden in verschiedene Geräteklassen eingeteilt, die wiederum bestimmte Pflichtkommandos und Pflichtfunktionen implementieren müssen.
Quelle: wiki

Heisst, habe ich ein Z-Wave device kann ich generell auf der untersten Ebene erwarten, dass das Ding auch als solches erkannt wird, da die Devices diese Infos bei haben... hat der LM nun ein Aktor als Aktor gekennzeichnet, sollte dieses ja irgendwo mitgegeben werden.... der interne Air-Sensor wurde offenbar als Sensor abgelegt / getagged, folgerichtig wird diese Info dann weitergegeben an die API und IH kann dieses auslesen um dann wiederrum die korrekten Widgets bereitzustellen. Habe ich diese Info nicht, dann weiss IH nicht, was es anbieten soll und folgerichtig habe ich eine leere Hülle.... der Air gibt immer noch ein device weiter, welches nun aber durch JBMedia mit der neuen FW offenbar anders gehändelt wird - vielleicht fehlt auch nur ein Tag / Flag, da der Sensor in der Zone ja auch selber nicht auftaucht....
Wenn dieses so ist, dann dürfte es kein Problem sein, alle anderen Sensoren ebenso zu flaggen / taggen, so dass die API diese Info an IH weitergeben kann....
Heiko
Beiträge: 711
Registriert: Sa 20. Feb 2016, 21:16
Wohnort: Dortmund

Sa 6. Apr 2019, 18:08

Jetzt auch von Simon auf Fachchinesisch gut beschrieben... :D
BG

Heiko
paulinchen
Beiträge: 303
Registriert: Di 28. Feb 2017, 14:15

Sa 6. Apr 2019, 18:28

Siutsch hat geschrieben:
Sa 6. Apr 2019, 14:19
Da Du ja auch schon lange im Forum unterwegs bist, sollte Dir auch längst aufgefallen sein, dass sich JBMedia mit derlei Infos und auch der Beantwortung direkter Fragen leider recht schwer tut.

Andere Hersteller können sowas übrigens, da gibt es "Milestones" oder was ähnliches und hier und da mal ne Info, was noch so geplant ist oder an was man vielleicht gerade noch arbeitet, schadet ja nun wirklich nicht.
Und auch die Frage / Bitte, warum man als User (der mit dem LM vielleicht mehr macht, als der Durchschnitt) hierbei nicht auch helfen kann (Betatests oder sowas) blieb unbeantwortet.
Wieder eine neue Version ohne vorherige Tests und direkt vor dem WE.
Das hatten wir doch schon ein paar mal, hat selten funktioniert.
Und wieder ist es exakt so gekommen, wie befürchtet:
Da wird am Freitagabend eine neue, ungetestete Version raus gehauen. Natürlich wieder ohne genaue Beschreibung usw.
jbmedia hat geschrieben:
Fr 5. Apr 2019, 21:15
Genau, es ist online! :) Die ausführliche Beschreibung der neuen Features erscheint leider erst am Montag. So bleiben einige Funktionen vermutlich vorerst unentdeckt.
Warum erscheint die Version dann nicht am Montag, wenn alles fertig ist und auch jemand ansprechbar ist?

Klar, so können sich alle schon mal am Wochenende wegen der neuen Fehler etwas aufregen und der Programmierer kann am Montagmittag gleich wieder voll durchstarten um die ersten Bugs zu fixen...
Dann werden sicher wieder täglich neue Versionen (natürlich auch noch unter der gleichen Versionsnummer) verteilt, damit dann wieder überhaupt niemand mehr weis, was mit welcher Version geht und was nicht.

Ein vernünftiges Change-Log, Beta-Tests usw. werden hier zwar immer wieder gefordert, aber von jbmedia hartnäckig ignoriert :cry:

Das bereitstellen der alten Versionen hatten wir uns doch auch hart erkämpft. Ist wohl mit dem neuen Design auch wieder weggefallen. Selbst die Version 8.5.1 kann man nicht laden, da kommt auch nur die V9!

Schade, wieder nichts dazugelernt.
Dos
Beiträge: 379
Registriert: Di 13. Sep 2016, 18:19

Sa 6. Apr 2019, 19:08

Was für eine sinnlose Diskussion.

Es erfolgte ja kein „Zwangsupdate“ dann hätte ich die Aufregung verstanden.
korken
Beiträge: 153
Registriert: Mi 24. Feb 2016, 18:40

Sa 6. Apr 2019, 19:57

Du hast recht wenn du sagst jbmedia ist für die Programmierung der API und der Korrektheit derselben zuständig. Habe ich auch nie bestritten und schon gar keinen haftbar gemacht
Der interne Sensor sollte normalerweise auch weiter funktionieren.
Ich bezog mich eher auf die Anzeige der Funksensoren die nachträglich implementiert wurden.
Simon hat geschrieben:
Sa 6. Apr 2019, 17:55
Dein Strassenvergleich hinkt... ;)
Weil dafür diverse Firmen miteinander kombiniert werden müssen....
Wenn der Apfel eine falsche Navi-SW baut, welche eine Strasse anstatt eine Klippe erkennt, dann ist da nicht die Stadt für verantwortlich sondern der Hersteller der dubiosen Navi-SW!

Ein schönes Beispiel ist Z-Wave. Dort wurden minimale Standards vereinbart, damit die devices generell funktionieren...
Eine Besonderheit von Z-Wave ist die Vereinheitlichung der Anwenderebene, um die Interoperabilität von Geräten unterschiedlicher Hersteller zu gewährleisten. Z-Wave-Geräte werden in verschiedene Geräteklassen eingeteilt, die wiederum bestimmte Pflichtkommandos und Pflichtfunktionen implementieren müssen.
Also gibts du mir doch recht, wenn du sagst der Navi Hersteller ist verantwortlich.
Auch dein Zigbee Vergleich sagt ja nur das die Geräte auf der untersten Ebene minimale Standards haben. Alles was darüber hinaus geht muss derjenige umsetzen der eine entsprechende App Programmieren will um alle Funktionen zu nutzen.
Antworten