Beiträge von idallen

Liebe Forumsmitglieder,

wir möchten Euch darüber informieren, dass das Forum aufgrund von Wartungsarbeiten vom 27.11.2024 bis zum 29.11.2024 nicht, oder nur eingeschränkt verfügbar sein wird. Während dieser Zeit führen wir nicht nur technische Anpassungen durch, sondern nehmen auch einige umfangreiche visuelle Änderungen vor.

Nach Abschluss der Arbeiten wird aus dem "Smarthome-Forum" das neue "Shelly-Forum". Damit wollen wir Euch ein noch moderneres und übersichtlicheres Erlebnis bieten.

Wir danken Euch schon jetzt für Eure Geduld während dieser Umstellung. Solltet Ihr nach den Wartungsarbeiten Fragen oder Anmerkungen haben, könnt Ihr uns jederzeit unter forum.de@shelly.com kontaktieren.

Vielen Dank für Eure Unterstützung und auf viele weitere spannende Diskussionen in unserem neuen Shelly-Forum!

Euer Shelly DACH Team

  • DS18B20 temperature sensor 1-Wire "hwID" ID numbers are backwards - wrong order of bytes

    The Shelly UNI shows (via MQTT) DS18B20 temperature sensor 64-bit hardware IDs ("hwID") like this: 28e60376e0013c74, 28f91176e0013cf4, 2861a676e0013cfa, 28765576e0013ccc, 28567976e0013ca3.

    Here's an example line from an MQTT subscription: {"0":{"hwID":"28f91176e0013cf4","tC":24.6}}

    Given that the least significant (rightmost) byte is supposed to be the device type (which should be identical for all sensors) and the most significant byte (leftmost) byte is supposed to be the CRC (which will likely differ between devices), I think the Shelly UNI firmware is generating these hardware IDs in reverse byte order. The last byte should be the first byte, etc. (Reference: https://www.smarthome-forum.eu)

    Tasmota software flashed on the same UNI only shows the middle 48-bits of the 64-bit ID, and it shows those bytes in the opposite byte order: 3C01E07603E6, 3C01E07611F9, 3C01E076A661, 3C01E0765576, 3C01E0767956 These five sensors have IDs that differ only in the last, least-significant 16 bits using Tasmota byte order. Using stock Shelly UNI byte order, the IDs differ all over the place -- another clue that the order of the "hwID" bytes is reversed by the stock Shelly UNI firmware.

    See also: https://www.smarthome-forum.eu

  • attaching DS18B20 temperature sensors to Shelly UNI under Tasmota

    From this URL https://www.smarthome-forum.eu we get a Tasmota Configuration template and corresponding list of GPIO settings that are supposed to match the Shelly UNI, but GPIO05 is wrong because there is no AM2301 temperature sensor on the UNI unless you attach one:

    Code
    {"NAME":"Shelly Uni","GPIO":[320,0,0,0,225,1216,0,0,192,193,194,224,0,4864],"FLAG":0,"BASE":18}

    I happen to have Shelly DS18B20 sensors attached to my UNI, and using the Tasmota web interface "Configure Template" to set GPIO05 to "DS18x20 1" (or use "Configure Other" to change the template number for GPIO05 from 1216 to 1312) is what enabled my eight DS18B20 sensors to be detected. (You can have more than eight if you recompile Tasmota, see https://www.smarthome-forum.eu)

    Alas, the Tasmota 13.0.0 firmware doesn't report the same DS18B20 ID numbers as the stock Shelly UNI firmware. Tasmota only reports the middle 48 bits of the 64-bit ID number (it leaves off the trailing CRC byte and the leading device type byte) and the 8-bit bytes (two hex digits) are in reverse order from the stock Shelly UNI firmware:

    Given that the Tasmota ID numbers only differ in the last 16 bits, but the Shelly ID numbers differ all over the place, I suspect the Tasmota has the right byte order and the Shelly is mixing up the byte order.

    https://www.smarthome-forum.eu