Closed zolee28 closed 3 years ago
Hi @zolee28 - there is an MQTT implementation using this library that should work with OpenHAB:
https://github.com/jimtng/dscalarm-mqtt
What issues did you run into using the HomeAssistant-MQTT
example with OpenHAB? That and the Homebridge-MQTT
example should provide all of the alarm states, but likely in a different format than OpenHAB is configured to accept.
@zolee28 I've added an example for openhab things/items in the readme here https://github.com/jimtng/dscalarm-mqtt/blob/develop/README.md
Note that OpenHAB will also auto detect this and add it to the Inbox, however I haven't tested using the auto-detected Thing, and instead I used a manual things file as per the readme.
Although I haven't actually tried / had a close look at the HomeAssistant example, I believe OpenHAB can also use it, given the right .things file. I just preferred writing my own implementation.
Hello,
@taligentx thanks a lot for the info, I did not know about this, I'll try it out. The main problem HomeAssistant-MQTT was that I could not find out the right path where it publishes the data. So I've tried a lot of variants like what to set in OpenHab items file, ex. to listen to this channel: dsc/Get/Zone1 and so on, but nothing worked.
@jimtng thanks for the examples, I'll try them out, but first I'm quite sure I'll will have to go through the setup phase, which consists of this step "Connect to "Homie-xxxxx" access point". So as I'm only a hobbyist programmer, do I connect with PuTTy thourgh SSH? or how do I upload the config.json to my ESP?
An easy way to set up a Homie device:
Step 1: Using your laptop, open this page: http://homieiot.github.io/homie-esp8266/configurators/v2/ - leave this page open on your browser, then proceed to step 2
Step 2: Using that same laptop, change your wifi to "Homie-something" SSID
Step 3: Go back to that browser page you opened in step 1. It should detect the Homie device and proceed through the steps. Once it's done, the ESP8266 will reboot and connect to your wifi network and your mqtt server
Step 4: Change your wifi back to your usual access point for your home network.
You can find more information here: https://homieiot.github.io/homie-esp8266/docs/develop-v3/configuration/json-configuration-file/ and here: https://homieiot.github.io/homie-esp8266/docs/develop-v3/configuration/http-json-api/
So I've started it, and got stuck at the configuration unfortunately. Figured out in one hour that I will not be able to upload the code to the ESP with Arduino IDE, then switched over to PIO-Visual Studio Code. Got the stuff uploaded, and I've tried to configure it, with cURL (cool that I know now what it's all about), by phone, and by a laptop with no success. I got this error.
Triggering Wi-Fi scan... ✔ Wi-Fi scan completed Received CORS request for /config Received config request ✖ Cannot mount filesystem ✔ Configured ↻ Rebooting into normal mode... ets Jan 8 2013,rst cause:2, boot mode:(3,7) load 0x4010f000, len 1384, room 16 tail 8 chksum 0x2d csum 0x2d v8b899c12 ~ld
Continuing searching for the right move, this did the trick. https://github.com/esp8266/Arduino/issues/1328#issuecomment-495515009
So it's a work in progress for tomorrow, will continue to update this, might help others out.
I've added an OpenHAB-MQTT
example, it's quite basic but can be customized to add in all of the other status items as seen in the Status
example. This is mostly a proof of concept and includes Arduino support, see @jimtng's Homie implementation for a more thorough example.
The existing HomeAssistant-MQTT
and Homebridge-MQTT
examples weren't useable as-is because OpenHAB's MQTT component uses the same MQTT values for getting the state and setting the state and I didn't see an obvious way to specify separate values as used in the other MQTT sketches.
Post back if you get a chance to check it out, I haven't worked with OpenHAB much because while it provides a very granular level of control and abstraction, it didn't seem to have any built-in logic for specialized components like security systems (handling armed/disarmed states, etc). I suspect that adding other states (like exit delay) will require adding OpenHAB rules to make sure the other states are updated appropriately (for example - turning off exit delay when the system goes into the armed state).
OpenHAB's MQTT component uses the same MQTT values for getting the state and setting the state
You could use transformations (e.g. map transformation) for mqtt status and for command separately. It would translate any value to ON/OFF in either direction (status or command), however, it only works on openhab 2.5M1. The transformation feature didn't work on openhab 2.4.
I got a compilation error for Openhab-MQTT:
Processing nodemcuv2 (platform: espressif8266; board: d1; framework: arduino)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif8266/d1.html
PLATFORM: Espressif 8266 2.2.2 > WEMOS D1 R1
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
PACKAGES: toolchain-xtensa 2.40802.190218 (4.8.2), tool-esptool 1.413.0 (4.13), tool-esptoolpy 1.20600.0 (2.6.0), framework-arduinoespressif8266 2.20502.0 (2.5.2)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 37 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <PubSubClient> 2.7
|-- <ESP8266WiFi> 1.0
|-- <dscKeybusInterface> 1.2.1
Compiling .pio\build\nodemcuv2\src\main.cpp.o
Compiling .pio\build\nodemcuv2\lib2ab\ESP8266WiFi\ESP8266WiFiMulti.cpp.o
Compiling .pio\build\nodemcuv2\lib2ab\ESP8266WiFi\ESP8266WiFiSTA-WPS.cpp.o
Compiling .pio\build\nodemcuv2\lib2ab\ESP8266WiFi\ESP8266WiFiSTA.cpp.o
src\main.cpp: In function 'void setup()':
src\main.cpp:147:20: error: 'mqttCallback' was not declared in this scope
mqtt.setCallback(mqttCallback);
^
src\main.cpp:148:19: error: 'mqttConnect' was not declared in this scope
if (mqttConnect()) mqttPreviousTime = millis();
^
src\main.cpp: In function 'void loop()':
src\main.cpp:160:14: error: 'mqttHandle' was not declared in this scope
mqttHandle();
^
src\main.cpp:162:7: error: 'class dscKeybusInterface' has no member named 'loop'
dsc.loop();
^
src\main.cpp:191:60: error: 'publishState' was not declared in this scope
publishState(mqttPartitionTopic, partition, "A");
^
src\main.cpp:196:60: error: 'publishState' was not declared in this scope
publishState(mqttPartitionTopic, partition, "S");
^
src\main.cpp:201:61: error: 'publishState' was not declared in this scope
else publishState(mqttPartitionTopic, partition, "D");
^
src\main.cpp:210:60: error: 'publishState' was not declared in this scope
publishState(mqttPartitionTopic, partition, "P");
^
src\main.cpp:215:58: error: 'publishState' was not declared in this scope
publishState(mqttPartitionTopic, partition, "D");
^
src\main.cpp:223:58: error: 'publishState' was not declared in this scope
publishState(mqttPartitionTopic, partition, "T");
^
src\main.cpp:232:53: error: 'publishState' was not declared in this scope
publishState(mqttFireTopic, partition, "1"); // Fire alarm tripped
^
src\main.cpp:235:53: error: 'publishState' was not declared in this scope
publishState(mqttFireTopic, partition, "0"); // Fire alarm restored
^
src\main.cpp: In function 'void mqttHandle()':
src\main.cpp:319:23: error: 'mqttConnect' was not declared in this scope
if (mqttConnect()) {
^
src\main.cpp: In function 'bool mqttConnect()':
src\main.cpp:334:9: error: 'class dscKeybusInterface' has no member named 'resetStatus'
dsc.resetStatus(); // Resets the state of all status components as changed to get the current status
^
*** [.pio\build\nodemcuv2\src\main.cpp.o] Error 1
And for some reason I got this error in OpenHAB for the Homie-DSC-MQTT:
2019-07-13 15:54:02.517 [me.event.InboxRemovedEvent] - Discovery Result with UID 'mqtt:homie300:mosquito:dsc' has been removed.
2019-07-13 15:54:02.523 [hingStatusInfoChangedEvent] - 'mqtt:homie300:mosquito:dsc' changed from UNINITIALIZED to INITIALIZING
2019-07-13 15:54:02.688 [hingStatusInfoChangedEvent] - 'mqtt:homie300:mosquito:dsc' changed from INITIALIZING to ONLINE
2019-07-13 15:54:02.792 [me.event.ThingUpdatedEvent] - Thing 'mqtt:homie300:mosquito:dsc' has been updated.
==> /var/log/openhab2/openhab.log <==
2019-07-13 15:54:03.058 [WARN ] [ic.internal.convention.homie300.Node] - Could not subscribe
java.util.concurrent.CompletionException: java.lang.Exception: Did not receive mandatory topic value: homie/dsc/alarm/power-trouble/$name
at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:292) ~[?:?]
at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:308) ~[?:?]
at java.util.concurrent.CompletableFuture.biRelay(CompletableFuture.java:1284) ~[?:?]
at java.util.concurrent.CompletableFuture$BiRelay.tryFire(CompletableFuture.java:1270) ~[?:?]
at java.util.concurrent.CompletableFuture$CoCompletion.tryFire(CompletableFuture.java:1020) ~[?:?]
at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) ~[?:?]
at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) ~[?:?]
at org.eclipse.smarthome.binding.mqtt.generic.internal.mapping.SubscribeFieldToMQTTtopic.timeoutReached(SubscribeFieldToMQTTtopic.java:163) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.lang.Exception: Did not receive mandatory topic value: homie/dsc/alarm/power-trouble/$name
at org.eclipse.smarthome.binding.mqtt.generic.internal.mapping.SubscribeFieldToMQTTtopic.timeoutReached(SubscribeFieldToMQTTtopic.java:161) ~[?:?]
... 7 more
==> /var/log/openhab2/events.log <==
2019-07-13 15:54:04.320 [me.event.ThingUpdatedEvent] - Thing 'mqtt:homie300:mosquito:dsc' has been updated.
Any hints how to proceed further, or what did I miss? Could be a bad connection (mixed wires - although I've rechecked the wiring a few times) to the DSC panel? Anything special I have to set up in DSC?
Edit: https://github.com/eclipse/smarthome/issues/6828 - there is some communication error between the "new" MQTT addon and Homie. I'll keep looking.
@zolee28 did you use the things / items files from the readme file? I haven't tried the automatic discovery yet. Which version of openhab are you using? I'm using 2.5M1.
@zolee28 I've just had a look at this particular issue / error message you reported:
java.util.concurrent.CompletionException: java.lang.Exception: Did not receive mandatory topic value: homie/dsc/alarm/power-trouble/$name
This error can be safely ignored. It will still work on openhab as is.
If you used the manual things file, it won't expect the full Homie convention so you won't see this error.
OK, after trying it out with the OpenHAB Homie autodiscovery, I don't think it would work. There is another issue where the Item Type is set to "dummy" in the PaperUI with no apparent way to change it.
I suggest not to use the autodiscovery, but instead, use the things file as per the example in README.md file (https://github.com/jimtng/dscalarm-mqtt/tree/develop#openhab-example). It works fine with it.
I got a compilation error for Openhab-MQTT: ... Compiling .pio\build\nodemcuv2\src\main.cpp.o
You'll need to use the original filename extension of .ino
instead of .cpp
- Arduino source files need additional processing by the IDE (Arduino IDE or PlatformIO) to be valid and PlatformIO will only do this if the file extension is correct.
1.2.1
For the OpenHAB example, you will probably need to manually install the develop
branch of this library. The version is currently listed as 1.3
in develop but that may change - I'm tidying up a few things and then should be able to finally push the next release so it can be installed and used directly from within PlatformIO.
So right now I went on with taligentx's solution. Thanks a lot for the hints, I managed to comply and upload it. I almost got teary eyed when I saw the logs but my happiness was short lived. Communication is ok now. The problem now comes from the DSC-EPS8266 connection, it seems that something with the wiring is messed up, because I do not get updates for the Zones.
2019-07-14 14:39:42.500 [vent.ItemStateChangedEvent] - partition1_armed_away changed from NULL to OFF
2019-07-14 14:39:42.504 [vent.ItemStateChangedEvent] - zone1 changed from NULL to CLOSED
2019-07-14 14:39:42.510 [vent.ItemStateChangedEvent] - partition1_triggered changed from NULL to CLOSED
2019-07-14 14:39:42.514 [vent.ItemStateChangedEvent] - partition1_armed_stay changed from NULL to OFF
2019-07-14 14:39:42.517 [vent.ItemStateChangedEvent] - zone2 changed from NULL to CLOSED
it seems that something with the wiring is messed up, because I do not get updates for the Zones.
Try the KeybusReader
sketch, you should see data coming from the panel and also be able to type in numbers to control the panel if the wiring is correct.
Happy day! Works. Worked with the KeybusReader sketch, so I've traced back my issue. The problem was a compilation error. Mainly the board type selected was not the right one (even though the sketch was uploaded on the ESP). I will also make a new PCB, for me the 3.3V voltage regulator gets quite hot, so probably there's a better way to tune down the voltage with a DC-DC converter. I'll share it when I'm done, and you can decide whether you put it next to the other PCB designs or not. Thanks again for the help guys. I might test jimtng's addon as well later, so I keep this open.
Great to hear - as far as power, there are some notes in the develop branch README.md
as well as discussion in issue #81.
Finally I took the effort to make a PCB with NodeMCU+LM2596 voltage regulator. I've attached below a screenshot and the gerber files, which you can upload directly to jlcpcb.com for example (it's the easiest - instead of making a PCB yourself). I have not tested it yet, but when I'm done I'll get back with some pictures. SH_DSC_2019-08-29.zip
Great, thanks for the contribution! Feedback from the populated PCB would be great.
Finally, the PCB arrived from the land of the rising sun. Everything works, however the NodeMCU block I've downloaded is around 4mm wider, so you have to bend the pins AND the holes are not matching the side of the case but I'll do an update soon of the PCB.
Until then, some pictures. It turned out quite good.
And one question, when I arm the system from Openhab, I get the folowing: Wondering what the 1P means, and how should it be ignored, so I do not get the warnings.
2019-10-02 22:30:21.087 [ome.event.ItemCommandEvent] - Item 'partition1_armed_away' received command ON
2019-10-02 22:30:21.098 [nt.ItemStatePredictedEvent] - partition1_armed_away predicted to become ON
2019-10-02 22:30:21.128 [vent.ItemStateChangedEvent] - partition1_armed_away changed from OFF to ON
2019-10-02 22:30:21.136 [vent.ChannelTriggeredEvent] - mqtt:broker:mosquito:dsc triggered 1A
==> /var/log/openhab2/openhab.log <==
2019-10-02 22:30:21.967 [WARN ] [eneric.internal.generic.ChannelState] - Command '1P' not supported by type 'OnOffValue': No enum constant org.eclipse.smarthome.core.library.types.OnOffType.1P
2019-10-02 22:30:21.971 [WARN ] [eneric.internal.generic.ChannelState] - Command '1P' not supported by type 'OnOffValue': No enum constant org.eclipse.smarthome.core.library.types.OnOffType.1P
2019-10-02 22:30:21.977 [WARN ] [eneric.internal.generic.ChannelState] - Command '1P' not supported by type 'OnOffValue': No enum constant org.eclipse.smarthome.core.library.types.OnOffType.1P
==> /var/log/openhab2/events.log <==
2019-10-02 22:30:21.985 [vent.ChannelTriggeredEvent] - mqtt:broker:mosquito:dsc triggered 1P
2019-10-02 22:30:28.366 [ome.event.ItemCommandEvent] - Item 'partition1_armed_away' received command OFF
2019-10-02 22:30:28.378 [nt.ItemStatePredictedEvent] - partition1_armed_away predicted to become OFF
2019-10-02 22:30:28.395 [vent.ItemStateChangedEvent] - partition1_armed_away changed from ON to OFF
Late response, the 1P
status indicates that the partition is in exit delay (pending) and is a leftover from the other MQTT examples, I didn't setup a switch in OpenHAB for exit delay so I've removed it from the example. The exit delay will still show up as a message in the partition status string so this shouldn't have much of an impact. If there's a useful function for having exit delay as a separate switch then let me know.
Did you ever get a chance to update the PCB for the correct pin spacing?
The OpenHAB-MQTT
sketch is now in newly released version 2.0, if there are any issues, feel free to re-open or post a new issue.
I have tried to use the ESP8266 HomeAssistant-MQTT.ino and tried to connect it with OpenHab. It did not work out, I do not know why.. Would it be a lot of work to make an example code for OpenHab through MQTT?