Mysensors Temperatursensor und das ID Feld

Begonnen von Sidey, 06 Oktober 2016, 23:12:21

Vorheriges Thema - Nächstes Thema

Sidey

Hallo ntruchsess,

Die Mysensors Lib unterstützt das Senden der Variable V_ID wenn ein Device S_TEMP definiert wird.
In V_ID lässt sich z.B. die Adresse eines DS18B20 Sensors speichern.

Damit das auch in FHEM dargestellt wird habe ich folgenden Patch erstellt.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Hauswart

#1
Hallo Sidey,

ich habe deine PN zu diesem Thema schon gelesen, leider noch nicht darauf geantwortet. Ich schaue mir deinen Patch gleich mal an. Und antworte nochmal ausführlicher.

Gruss




Edit: Ich denke ich nehme deinen Patch mal als Anregung die neuen Variablen aus der Lib 2.0 mal ins FHEM zu integrieren :) Stand derzeit müsste man die ID von Hand erstellen. Da ich die ID bei Temperatursensoren aber auch sinnvoll halte, füge ich diese in der Datei hinzu.
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

Sidey

Kein Problem, war jetzt keine große Änderung..

Was ich noch nicht gelöst habe ist, wie ich die ID hexadezimal übertragen und so auch in FHEM Anzeige.

Auf dem Mysensors habe ich die Adresse in einen Char Arrays konvertiert. Den Sende ich dann.

FHEM zeigt aktuelle eine Nummer als ID an.
Irgendwo muss man aber wohl das Format bestimmen können.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Beta-User

Zitat von: Sidey am 07 Oktober 2016, 08:56:15
Auf dem Mysensors habe ich die Adresse in einen Char Arrays konvertiert. Den Sende ich dann.

Kannst Du mal den Sketch posten?
Ich hatte das hier https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency/blob/master/DallasTemperatureSensor_Stored_ID/DallasTemperatureSensor_Stored_ID.ino auch mal vorbereitet, und meine mich erinnern zu können, dass das auch sinnvoll versendet wurde. Allerdings müßte ich den Sketch zum nochmaligen Testen dahingehend ändern, dass das mit der conversiontime anders gelöst wird (die Funktion ist in den neueren DallasTemp-Libs nicht mehr public vorhanden).

Gruß,

Beta-USer
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Hauswart

#4
Möchtest du mal folgende Dateien testen? Einen guten Sketch für ID + Temperatur habe ich derzeit nicht, habe mal einen angefangen aber nie 100% fertiggestellt.

https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/lib/Device/MySensors/Constants.pm
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/10_MYSENSORS_DEVICE.pm

Gruss und danke




Edit: Für das Speichern der ID im EEPROM gibt es neuerdings auch ein paar mehr Infos: https://www.mysensors.org/download/sensor_api_20#saving-state
Edit2: Genau mit Beta-User hatte ich vor Monaten schon mal geschaut gehabt :)
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

Sidey

Sketch der die ID mit sendet kann ich euch heute Abend bereitstellen.. das Senden und Empfang geht auch prinzipiell. Nur das Format ist nicht identisch.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Beta-User

Zitat von: Sidey am 07 Oktober 2016, 15:53:36
Sketch der die ID mit sendet kann ich euch heute Abend bereitstellen.. das Senden und Empfang geht auch prinzipiell. Nur das Format ist nicht identisch.

Habe eben den unten zitierten Sketch für MySensors 2.0.0 und DallasTemp 3.7.7 angepaßt nach github geladen...
Ist zwar etwas komplizierter, aber sollte zum Testen reichen...

Zusammenspiel mit dem .pm teste ich ggf. morgen.

Gruß

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Sidey

Hier mal mein Code für den Onewire Bus / Temperatur Sensoren.

Ich habe mir die Einzelnen Sensoren in eigenen header Dateien gespeichert und binde diese dann in meinem Hauptsketch ein.


tDSTemp.h

#define SER_DEBUG;

#ifdef SER_DEBUG
#define DEBUG_PRINTER Serial
#define DEBUG_PRINT(...) { DEBUG_PRINTER.print(__VA_ARGS__); }
#define DEBUG_PRINTLN(...) { DEBUG_PRINTER.println(__VA_ARGS__); }
#else
#define DEBUG_PRINT(x) {}
#define DEBUG_PRINTLN(x) {}
#endif



namespace tDS1822 {

#include "core/MyMessage.h"
#include "core/MySensorsCore.h"
#include "debug.h"
#include <OneWire.h>

// Struct for holding data for the temp sensors
struct ds182b0_sens_info {
DeviceAddress address;
// uint32_t  AddrTransmitted = false;
float lastTemp;
uint32_t lastSend;
};

ds182b0_sens_info TEMP_SENSOR_DATA[] ;


//#define SER_PRN 1
const bool _ACK = false;
const uint8_t _CHILD_ID_TEMP = 0; // First Child ID for Temp Sensors
const uint8_t _ONE_WIRE_BUS = 3; // Pin where dallase sensor is connected
const uint8_t _MAX_ATTACHED_DS18B20 = 16;  // Support not more than 16 sensors connected to this device
const uint32_t _SEND_FREQUENCY = 60520;
const uint8_t _TEMPERATURE_PRECISION = 11; //Max 12 bit, min 9 bit  / 9bit requres 95ms, 10bit 187ms, 11bit 375ms and 12bit resolution takes 750ms



boolean metric = true;
MyMessage msgTemp(_CHILD_ID_TEMP, V_TEMP);

OneWire oneWire(_ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);

uint8_t _NumSensors = 0;
const int16_t _CONVERSION_DELAY = 375;

void deviceAdresstoString(char *addr, DeviceAddress deviceAddress)
{
snprintf(addr, 24,"%02X%02X%02X%02X%02X%02X%02X%02X",
&deviceAddress[0], &deviceAddress[1], &deviceAddress[2], &deviceAddress[3],
&deviceAddress[4], &deviceAddress[5], &deviceAddress[6], &deviceAddress[7]); //snprintf

}

void setup() {
DEBUG_PRINTLN("DS1822: Init Sensor");
sensors.begin(); // Startup OneWire sensor
sensors.setWaitForConversion(false); // Make it async
};



void sendonce()
{

DEBUG_PRINTLN("DS1822: Transmit ID");
for (int i = _CHILD_ID_TEMP; i < _NumSensors; i++) {

}
}


void Transmit()
{
//Serial.println("s");
unsigned long now = millis();
static unsigned long lastSend = 0;
bool sendTime = now - lastSend > _SEND_FREQUENCY;
static bool tempRequested = false;


if (sendTime)
{


// First query the temperatur
if (!tempRequested) {
sensors.requestTemperatures();
tempRequested = true;
lastSend = now - _SEND_FREQUENCY + _CONVERSION_DELAY;
return;  // Return function, and wait additional delay
}

// second get the temperature
for (int i = _CHILD_ID_TEMP; i<_NumSensors; i++)
{
if (now < (uint32_t)_SEND_FREQUENCY * 2)
{
MyMessage msgID(_CHILD_ID_TEMP, V_ID);
char dA[24] = "";
deviceAdresstoString(dA, TEMP_SENSOR_DATA[i].address);
uint8_t len = strlen(dA);
// send(msgID.setSensor(i).set(dA, 8), true);  // Unspecified
send(msgID.setSensor(i).set(dA, true));    // Send as char
DEBUG_PRINT("DS1822: Transmitting ID / Sensor=");  DEBUG_PRINT(i); DEBUG_PRINT(" Address="); DEBUG_PRINT(dA); DEBUG_PRINT(" - "); DEBUG_PRINTLN(len);
}

// Transmit the sensor ID once
//if (TEMP_SENSOR_DATA[i].addr == false)
// Fetch and round temperature to one decimal
float temperature = static_cast<float>(static_cast<int>((metric ? sensors.getTempC(TEMP_SENSOR_DATA[i].address) : sensors.getTempF(TEMP_SENSOR_DATA[i].address)) * 10.)) / 10.;
// Only send data if temperature has changed and no error or if 3* send_Frequency is over without sending anythin expired
if (TEMP_SENSOR_DATA[i].lastTemp != temperature && temperature != -127.00 || TEMP_SENSOR_DATA[i].lastSend + (_SEND_FREQUENCY * 15) < now) {
// Send in the new temperature
send(msgTemp.setSensor(i).set(temperature, 1),_ACK);
TEMP_SENSOR_DATA[i].lastTemp = temperature;
TEMP_SENSOR_DATA[i].lastSend = now;
DEBUG_PRINT("DS1822: Transmitting -> ID:"); DEBUG_PRINT(i);  DEBUG_PRINT(", Temp="); DEBUG_PRINTLN(temperature);
}

}
lastSend = now;
tempRequested = false;


}

};

void presentation()
{

DEBUG_PRINTLN("DS1822: present sensors");

// Send the sketch version information to the gateway and Controller
sendSketchInfo("Temp DS1822 Sensors", "1.0", _ACK);
_NumSensors = min(sensors.getDeviceCount(), _MAX_ATTACHED_DS18B20);  // Get number of connected sensors
DEBUG_PRINT("DS1822: NumSensors="); DEBUG_PRINTLN(_NumSensors);


for (int i = _CHILD_ID_TEMP; i < _NumSensors; i++) {
present(i, S_TEMP, 'STEMP', _ACK);
sensors.getAddress(TEMP_SENSOR_DATA[i].address, i);
sensors.setResolution(TEMP_SENSOR_DATA[i].address, _TEMPERATURE_PRECISION);
}

DEBUG_PRINTLN("DS1822: sensors presented");

metric = getConfig().isMetric;
};




}


Mein Hauptsketch sieht dann so aus:
sketch.ino


void setup()
{
tDS1822::setup();
}

void presentation() {
tDS1822::presentation();
wdt_enable(WDTO_8S);
wdt_reset();
}


void loop() {
tDS1822::Transmit();
wdt_reset();
}


Wenn ich mittels

send(msgID.setSensor(i).set(dA, true));    // Send as char


Dann wird eine 32 übermittelt, obwohl das Format ja als P_STRING angegeben ist.

TSP:MSG:SEND 103-103-0-0 s=0,c=1,t=42,pt=6,l=1,sg=1,ft=0,st=ok:32
DS1822: Transmitting ID / Sensor=0 Address=26226326426526626726826 - 23


TSP:MSG:SEND 103-103-0-0 s=1,c=1,t=42,pt=6,l=1,sg=1,ft=0,st=ok:32
DS1822: Transmitting ID / Sensor=1 Address=27227327427527627727827 - 23


In Fhem steht dann auch eine 32 im Reading.


Wenn ich mittels

send(msgID.setSensor(i).set(dA, 8), true);  // Unspecified


dann kommt

TSP:MSG:SEND 40-40-255-0 s=0,c=1,t=42,pt=6,l=8,sg=1,ft=0,st=bc:3236323236333236
DS1822: Transmitting ID / Sensor=0 Address=26226326426526626726826 - 23


TSP:MSG:SEND 40-40-255-0 s=1,c=1,t=42,pt=6,l=8,sg=1,ft=0,st=bc:3237323237333237
DS1822: Transmitting ID / Sensor=1 Address=27227327427527627727827 - 23



In Fhem steht dann auch schön:
3236323236333236 bzw. 3237323237333237


Ziel wäre es aber aus meiner Sicht 27227327427527627727827  zu übergeben und in FHEM auch darzustellen.
Wie machen wir das jetzt?

Grüße Sidey

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Beta-User

#8
Zitat von: Hauswart am 07 Oktober 2016, 09:35:12
Möchtest du mal folgende Dateien testen? Einen guten Sketch für ID + Temperatur habe ich derzeit nicht, habe mal einen angefangen aber nie 100% fertiggestellt.

https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/lib/Device/MySensors/Constants.pm
https://raw.githubusercontent.com/Kolbi/fhem-mirror/master/fhem/FHEM/10_MYSENSORS_DEVICE.pm

Test gemacht, hat mir den MySensors-Teil zerschossen, habe jetzt nur den patch von Sidey in die Standard-pm eingearbeitet.
Das Übertragen der ID funktioniert mit folgendem Sketch, der die ID dann im allgemeinen HEX-Format (wie z.B. von OWX bekannt) überträgt.

Wenn ich noch Lust habe, mache ich evtl. das Drumrum weg, damit das evtl. auch nach MySensors weitergeben kann (Danke Hauswart!).

Zitat von: Sidey am 07 Oktober 2016, 22:20:54
Ziel wäre es aber aus meiner Sicht 27227327427527627727827  zu übergeben und in FHEM auch darzustellen.
Wie machen wir das jetzt?
Hallo Sidey,

das wird in der Form nicht klappen, da es eine Längenbegrenzung für die zu übertragenden Daten gibt, es wird also immer irgendwo was abgeschnitten werden (nach meiner Erfahrung aber hinten).

/**
   The MySensors Arduino library handles the wireless radio link and protocol
   between your home built sensors/actuators and HA controller of choice.
   The sensors forms a self healing radio network with optional repeaters. Each
   repeater and gateway builds a routing tables in EEPROM which keeps track of the
   network topology allowing messages to be routed to nodes.
   Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
   Copyright (C) 2013-2015 Sensnology AB
   Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
   Documentation: http://www.mysensors.org
   Support Forum: http://forum.mysensors.org
   This program is free software; you can redistribute it and/or
   modify it under the terms of the GNU General Public License
   version 2 as published by the Free Software Foundation.
*******************************
   DESCRIPTION
   Example sketch showing how to send in DS1820B OneWire temperature readings back to the controller
   http://www.mysensors.org/build/temp
   Enhanced Version to keep SensorID icluding a lot of ideas from leodesigner and hauswart (forum.fhem.de)
   Improvements:
   - it will remember a sensor index in EEPROM (2 bytes per sensor)
      in case if you need to replace or add new sensor to the 1Wire bus - all other sensors will keep own sensor index#
  Last modifications:
  - Revert back to standard Mysensor EEPROM storage (in line with leodesigner code base)
  - First ID for DS has to be defined
  - Bug fixed with not changed "spot_used" value
  - Present Dallas-Hardware-ID as comment (still not working!!!)
  - Improve reading of code by opting for some more subroutines
*/

// Enable debug prints to serial monitor
#define MY_DEBUG
// Enable and select radio type attached
#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69
#include <SPI.h>
#include <MySensors.h>
#include <DallasTemperature.h>
#include <OneWire.h>
#define COMPARE_TEMP 1 // Send temperature only if changed?
#define ERASE_HASH // Clear EEPROM, if no 1w-device is present?
#define SEND_ID // Send also Dallas-Addresses?
#define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected
#define MAX_ATTACHED_DS18B20 16
#define EEPROM_DEVICE_ADDR_START  64     // start byte in eeprom for remembering our sensors
#define EEPROM_DEVICE_ADDR_END    EEPROM_DEVICE_ADDR_START+MAX_ATTACHED_DS18B20*2

uint8_t DS_First_Child_ID = 7; //First Child-ID to be used by Dallas Bus; set this to be higher than other Child-ID's who need EEPROM storage to avoid conflicts
uint16_t SLEEP_TIME = 30000; // Sleep time between reads (in milliseconds)
OneWire oneWire(ONE_WIRE_BUS); // Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
DallasTemperature sensors(&oneWire); // Pass the oneWire reference to Dallas Temperature.
float lastTemperature[MAX_ATTACHED_DS18B20];
uint8_t numSensors = 0;
DeviceAddress tempDeviceAddress; // We'll use this variable to store a found device address
int  resolution = 12;
int  conversionTime = 0;
char* charAddr = "Check for faults";
uint8_t ts_spot[MAX_ATTACHED_DS18B20]; // array for matching bus-id to EEPROM-index
bool spot_used[MAX_ATTACHED_DS18B20]; // used spot array
// Initialize temperature message
MyMessage msgTemp(0, V_TEMP);
#ifdef SEND_ID
MyMessage msgId(0, V_ID);
#endif
boolean receivedConfig = false;
boolean metric = true;
boolean IDsSent = false;


void before() {
  conversionTime = 750 / (1 << (12 - resolution));
  // Startup up the OneWire library
  sensors.begin();
  // requestTemperatures() will not block current thread
  sensors.setWaitForConversion(false);
  // Fetch the number of attached temperature sensors
  numSensors = sensors.getDeviceCount();
  // use the 1.1 V internal reference
  initialiseIdArray();
}


// Initialize temperature message
void setup() {
}

void presentation() {
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo("Temperature Sensor", "1.3");
  // Present all sensors to controller
  for (int i = 0; i < numSensors && i < MAX_ATTACHED_DS18B20; i++) {
    sensors.getAddress(tempDeviceAddress, i);
    Serial.print("Hardware presented: ");
    charAddr = addrToChar(tempDeviceAddress);
    Serial.println(charAddr);
    present(ts_spot[i], S_TEMP);
    sensors.setResolution(tempDeviceAddress, resolution);
  }
}
void loop() {
  // Fetch temperatures from Dallas sensors
  sensors.requestTemperatures();
  // query conversion time and sleep until conversion completed
  // sleep() call can be replaced by wait() call if node need to process incoming messages (or if node is repeater)
  wait(conversionTime);
  // Read temperatures and send them to controller
  for (int i = 0; i < numSensors && i < MAX_ATTACHED_DS18B20; i++) {
    // Fetch and round temperature to one decimal
    float temperature = static_cast<float>(static_cast<int>((getConfig().isMetric ? sensors.getTempCByIndex(i) : sensors.getTempFByIndex(i)) * 10.)) / 10.;
    // Only send data if temperature has changed and no error
#if COMPARE_TEMP == 1
    if (lastTemperature[i] != temperature && temperature != -127.00 && temperature != 85.00) {
#else
    if (temperature != -127.00 && temperature != 85.00) {
#endif
      // Send in the new temperature
      send(msgTemp.setSensor(ts_spot[i]).set(temperature, 1));
      // Save new temperatures for next compare
      lastTemperature[i] = temperature;
#ifdef SEND_ID
      if (!IDsSent) {
      //8 sorgt dafür, dass alle 16 Stellen übermittelt werden
      send(msgId.setSensor(ts_spot[i]).set(tempDeviceAddress, 8));
      IDsSent = true;
      }
#endif
    }
  }
  wait(SLEEP_TIME);
}

// Subroutines
//##########################################################
//
void initialiseIdArray() {
  uint8_t knownSensors = 0;
#ifdef ERASE_HASH
  if (numSensors < 1) {
    for (uint8_t i = EEPROM_DEVICE_ADDR_START; i < EEPROM_DEVICE_ADDR_END + 1; i++) {
      saveState(i, 0xFF); //0xFF seems to be better in line with mysensors standards, was 0x00
    }
    Serial.println("EEPROM cleared...");
  }
#endif
  //initialise spot_used array to default false
  for (uint8_t i = 0; i < MAX_ATTACHED_DS18B20; i++) {
    spot_used[i] = false;
  }
  // first loop: filling Address-Array with IDs already stored, and clear used spot array
  for (uint8_t i = 0; i < numSensors && i < MAX_ATTACHED_DS18B20; i++) {
    sensors.getAddress(tempDeviceAddress, i);
    // check if we know this sensor
    int8_t sidx = getSensorIndex(tempDeviceAddress);
    if (sidx < 0) {
      ts_spot[i] = 0;
    }
    else {
      // we know this sensor
      ts_spot[i] = sidx + DS_First_Child_ID;
      spot_used[sidx] = true;
      knownSensors++;
    }
  }
#ifdef MY_DEBUG
  Serial.println();
  Serial.print(F("# Stored Devices: "));
  Serial.println(knownSensors);
#endif
  // second loop for filling Address-Array with IDs not stored yet
  for (uint8_t i = 0; i < numSensors && i < MAX_ATTACHED_DS18B20; i++) {
    sensors.getAddress(tempDeviceAddress, i);
    // check if we do not know this sensor yet
    if (ts_spot[i] == 0) {
      uint8_t k = getUnusedSpot();
      ts_spot[i] = k + DS_First_Child_ID;
      spot_used[k] = true;
      storeSensorAddr(tempDeviceAddress, k);
    }
  }
#ifdef MY_DEBUG
  for (int i = 0; i < numSensors && i < MAX_ATTACHED_DS18B20; i++) {
    sensors.getAddress(tempDeviceAddress, i);
    Serial.println();
    Serial.print(i);
    Serial.print(F(" index: "));
    Serial.print(ts_spot[i]);
    Serial.print(F(" address: "));
    charAddr = addrToChar(tempDeviceAddress);
    Serial.println(charAddr);
#endif
  }
}

// a simple hash function for 1wire address to reduce id to two bytes
uint16_t simpleAddrHash(DeviceAddress a) {
  return ((a[1] ^ a[2] ^ a[3] ^ a[4] ^ a[5] ^ a[6]) << 8) + a[7];
}

// search for device address hash in eeprom
// return -1 if not found
int8_t getSensorIndex(DeviceAddress a) {
  uint16_t hash = simpleAddrHash(a);
  int8_t idx = -1;
  uint8_t aidx = 0;
  uint8_t ptr = EEPROM_DEVICE_ADDR_START;
  while (ptr < EEPROM_DEVICE_ADDR_END && idx == -1) {
    uint8_t hash1 = loadState(ptr);
    uint8_t hash2 = loadState(ptr + 1);
    if ( hash1 == (uint8_t)(hash >> 8) && hash2 == (uint8_t)(hash & 0x00FF)) {
      // found device index
      idx = aidx;
    }
    aidx++;
    ptr += 2;
  }
  return idx;
}

// search for first unused spot in eeprom
uint8_t getUnusedSpot() {
  int8_t j = 0;
  while (spot_used[j] == true) {
    j++;
  }
  return j;
}

// save address hash in EEPROM under index
void storeSensorAddr(DeviceAddress a, uint8_t index) {
  uint16_t hash = simpleAddrHash(a);
  uint8_t ptr = EEPROM_DEVICE_ADDR_START + index * 2;
  if (ptr < EEPROM_DEVICE_ADDR_END) {
    saveState(ptr,   hash >> 8);
    saveState(ptr + 1, hash & 0x00FF);
  }
#ifdef MY_DEBUG
  Serial.print(F("storeSensorAddr under index: "));
  Serial.println(index);
#endif
}

char* addrToChar(uint8_t* data) {
  String strAddr = String(data[0], HEX); //Chip Version; should be higher than 16
  byte first ;
  int j = 0;
  for (uint8_t i = 1; i < 8; i++) {
    if (data[i] < 16) strAddr = strAddr + 0;
    strAddr = strAddr + String(data[i], HEX);
    strAddr.toUpperCase();
  }
  for (int j = 0; j < 16; j++) {
    charAddr[j] = strAddr[j];
  }
  return charAddr;
}
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

So,

anbei der auch auf Github abgelegte "abgespeckte" Sketch, der mit der 10_MYSENSORS-DEVICE.pm -Ergänzung von Sidey (sends: ... V_ID) funktioniert (nur 2 Sensoren zum Testen gehabt, aber das Prinzip scheint zu passen).

Schönes WE noch,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Sidey



Zitat von: Beta-User am 08 Oktober 2016, 14:52:24

Das Übertragen der ID funktioniert mit folgendem Sketch, der die ID dann im allgemeinen HEX-Format (wie z.B. von OWX bekannt) überträgt.
Was ist das allgemeine Hex Format und was ist OWX?
Kannst Du mal den Wert vom Reading Posten? Mir ist nicht klar, wie Mysensors wissen soll, dass der Wert hexadezimal übergeben wird.


Zitat von: Beta-User am 08 Oktober 2016, 14:52:24

das wird in der Form nicht klappen, da es eine Längenbegrenzung für die zu übertragenden Daten gibt, es wird also immer irgendwo was abgeschnitten werden (nach meiner Erfahrung aber hinten).

Nach meinen Recherchen 32 Byte.
Abzüglich Header lassen sich also 25 Zeichen übertragen.
Den Char Array den ich mittels SET übergeben habe ist kleiner.
Nach meinem Verständnis hätte es klappen müssen.
Ich habe es auch zum Testen mit 0xAB probiert, was ja definitiv nicht zu lange ist.
Es scheint so, als ob P_STRING irgendwo nicht ausgewertet wird.
Keine Ahnung, ob der Fehler im Gateway oder in FHEM liegt, so weit habe ich nicht geforscht.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Beta-User

Zitat von: Sidey am 09 Oktober 2016, 11:18:10
Was ist das allgemeine Hex Format und was ist OWX?
Kannst Du mal den Wert vom Reading Posten? Mir ist nicht klar, wie Mysensors wissen soll, dass der Wert hexadezimal übergeben wird.
Das reading sieht bei mir so aus:
id1 28FF3698541401C1 2016-10-08 15:42:21
Die ID wird also in einer Hexadezimal-Darstellung übertragen. OWX ist der Gerätetyp für eine OneWire-USB-Schnittstelle (=>commandref). Damit werden die Sensoren ebenfalls in einer hexadezimalen Form benamst (allerdings wird in der ROM-ID das erste Byte (Gerätetyp) und das letzte (CRC) dort jeweils mit einem Punkt abgesetzt).

Zitat von: Sidey am 09 Oktober 2016, 11:18:10
Mir ist nicht klar, wie Mysensors wissen soll, dass der Wert hexadezimal übergeben wird.
Ich habe jetzt nicht gesucht, aber m.E. verhält es sich so, dass Mysensors gar keinen bestimmten Datentyp verlangt bzw. überträgt, sondern schlicht eine maximale Menge Bytes als payload akzeptiert und diese dann über das GW an den Controller übergibt. Als welchen Datentyp der Controller (hier FHEM) dann diese payload interpretiert, kann dort frei definiert werden und es braucht Dich eigentlich in der Regel gar nicht zu kümmern.   
Deswegen war es z.B. möglich (anderer Sketch in meinem Repo), nicht nur einen "reinen" Infrarot-Sendebefehl zu übertragen, sondern gleich noch den Protokolltyp und die Länge (1 0x7E817E81 32 = POWEROFF auf meiner Yamaha) dazu. Lustige Sache, das 8).
Es gibt eine Begrenzung, die weniger wie die 25 Zeichen umfasst. Teste es ggf. einfach mal mit der Übertragung eines längeren Sketch-Namens, wenn Du es nicht glaubst.   ;)

Wie obiges reading zeigt, geht es jedenfalls mit dem Sketch aus meinem letzten Post; was dort aber seltsam war, war der Umstand, dass ich die ID's nicht einfach einmalig im Rahmen der Setup()-Routine übertragen konnte,  sondern diesen Umweg über die Abfrage brauchte, ob die ID's bereits gesendet wurden. Das erschließt sich mir nicht, aber was solls... ::)

Grüße,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Sidey

Ich probiere das noch mal aus, auch wenn ich der Meinung bin, es schon so gemacht zu haben... Die Zeile ist ja vorhanden nur im Beispiel aus kommentiert.
Wenn es bei dir geht, dann sollte es bei mir ja auch gehen.

Was den Datentyp angeht, so gibt es ja mehrere Versionen des Set Befehls in mymessage.h.

Wenn dort ein Char übergeben wird, dann wird der Datentyp P_String gesetzt, was damit passiert weiss ich nicht.
Irgendwie hatte ich angenommen, das wird im Controller ausgewertet.

Was das Senden der ID angeht hatte ich gleiche Erfahrungen.
Ich nehme an, man kann Werte erst übertragen wenn der Sensor registriert ist, das ist er halt in present() noch nicht.

Gruß Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Beta-User

Zitat von: Sidey am 09 Oktober 2016, 12:49:55
Was das Senden der ID angeht hatte ich gleiche Erfahrungen.
Ich nehme an, man kann Werte erst übertragen wenn der Sensor registriert ist, das ist er halt in present() noch nicht.

Dachte ich auch, war aber der Meinung, dass die MySensors-Logik der Abfolge der Abschnitte diese ist:
before()
presentation()
setup()

Damit hätte der Sensor eigentlich bereits präsent sein sollen ???.
Vielleicht mache ich mich nochmal dran, das auszutesten, ist ja eigentlich kein großer Aufwand, vielleicht lag es "nur" daran, dass ich den setup()-Teil vor der presentation() hatte...

Gruß,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Sidey

Ich hatte es in Präsentation, der Teil läuft nach Setup und wenn Präsentation durch ist, dann kommt ein registrieren.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Beta-User

Zitat von: Sidey am 09 Oktober 2016, 13:16:33
Ich hatte es in Präsentation, der Teil läuft nach Setup und wenn Präsentation durch ist, dann kommt ein registrieren.

Die 2.0.0 hat an der Stelle einen Bug, siehe hier:
https://github.com/mysensors/MySensors/issues/514

An sich hätte es gehen sollen, wenn die Info in der setup()-Routine drin ist. Das war m.E. mit einer der features, die man durch die Trennung von setup() in before() und setup() erreichen wollte. (siehe hier: https://github.com/mysensors/MySensors/releases)

Btw.: an sich wäre es besser, wenn die Info über die HW gleich mit als Kommentar/description übertragen wird (siehe hier:
void present(uint8_t childSensorId, uint8_t sensorType, const char *description, bool ack);.

Das kann aber FHEM nicht verwerten (?) und würde wohl tiefere Eingriffe in die 10_MYSENSORS-DEVICE.pm erforderlich machen. Damit könnte man aber die nummerische Benennung durch die HW-ID ersetzen, wenn sie mit übertragen würde. Wäre klasse, dann wäre nämlich die "Herkunft" der Temperatur-Daten genauso eindeutig wie über OWX und man bräuchte keine Klimmzüge um V_ID herum!

Das anzupassen übersteigt aber meine Kompetenzen... :'(
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Sidey

Ja, stimmt.
Ob das Tiefe Eingriffe Bedarf weiss ich nicht. Ist halt die Frage, wie FHEM die Beschreibung darstellen soll
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Beta-User

Na ja, am besten wäre es, statt "temperature" oder "temperature20" gleich die Hardware-Adresse als reading-Namen zu verwenden, (aber nur, wenn sie mit übermittelt wird). Dann bräuchte man sich über die Frage, ob bei jedem Neustart die Sensoren alle noch in der richtigen Reihenfolge sind, keine Gedanken zu machen.

(Und ja, es ist mir bekannt, dass es keine Probleme gibt, solange alle ursprünglich vorhandenen da sind. Bei einem Reboot soll angeblich die ursprüngliche Reihenfolge gleich bleiben. Lustig wird es erst, wenn zwischenzeitlich was passiert. Fehlt z.B. von ursprünglich 8 Sensoren die Nummer 4, dann kann aus 5/8 auch 4/7 werden... Oder es kommt einer hinzu, dann kann er Nummer 1/9 werden usw.).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Sidey

Ja, das habe ich mir auch so vorgestellt.

Irgendwo hatte ich ein Beispiel gefunden, da hat jemand eigene IDs im eeprom gespeichert um das Problem zu umgehen, aber eigentlich ist das auch eher ein Workaround.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Beta-User

#19
Zitat von: Sidey am 09 Oktober 2016, 15:54:07
Ja, das habe ich mir auch so vorgestellt.

Irgendwo hatte ich ein Beispiel gefunden, da hat jemand eigene IDs im eeprom gespeichert um das Problem zu umgehen, aber eigentlich ist das auch eher ein Workaround.

Na ja, den workaround kenne ich bestens 8): auf meinem Github-Repo findest Du zwei Versionen/Ansätze: direkte Addressierung über ein im Sketch gespeichertes Array und das Verhashen und Speichern im EEPROM 8)... Beide Versionen funktionieren in der Praxis tadellos seit mehreren Monaten, wenn Du also einen schnellen Fix für "Dein" Problem suchst. Die Array-Version funktioniert nur noch nicht mit den neueren Dallas-libs EDIT: Funktioniert vermutlich (mein Arduino scheint einen Hau zu haben, der letzte Sensor wird abgeschnitten) ;). Der Stored-ID-Sketch sieht zwar vertrackt aus, ich habe mir aber Mühe gegeben zu erklären, wie er funktioniert und wo was geklaut ist (=>github).

Bin jetzt auf 2.0.1, da funktioniert das übrigens tadellos mit setup() :) (Wenn man das GW auch auf 2.0.1 bringt ;))
EDIT: irgendwie wollte das GW nicht dauerhaft :'(

@Hauswart: Sketch (Einfaches Sende ID) ist auch auf github, kannst ihn nach optischer Anpassung gerne zu den Beispielsketchen bei MySensors-Contrib mit einchecken.

Gruß,

Beta-User 
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Sidey

ok Fehler gefunden.... argh


Ich hab nicht den Inhalt von deviceAddress in Hex umgewandelt, sonder die Adresse davon... Arghh:
Damit ist der String auch nur noch 16 Zeichen, wie es zu erwarten ist.

snprintf(addr, 18,"%02X%02X%02X%02X%02X%02X%02X%02X",
deviceAddress[0], deviceAddress[1], deviceAddress[2], deviceAddress[3],
deviceAddress[4], deviceAddress[5], deviceAddress[6], deviceAddress[7]); //snprintf
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Hauswart

Ich war leider das Wochenende über unterwegs und kann mich erst jetzt wieder durch die Beiträge arbeiten :)
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)