[QUESTION] support for MQTT+Openhab about dsckeybusinterface HOT 22 CLOSED

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

from dsckeybusinterface.

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.

from dsckeybusinterface.

@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.

from dsckeybusinterface.

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?

from dsckeybusinterface.

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.

from dsckeybusinterface.

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/

from dsckeybusinterface.

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.
esp8266/Arduino#1328 (comment)

So it's a work in progress for tomorrow, will continue to update this, might help others out.

from dsckeybusinterface.

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).

from dsckeybusinterface.

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.

from dsckeybusinterface.

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: eclipse-archived/smarthome#6828 - there is some communication error between the "new" MQTT addon and Homie. I'll keep looking.

from dsckeybusinterface.

@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.

from dsckeybusinterface.

@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.

from dsckeybusinterface.

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.

from dsckeybusinterface.

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.

from dsckeybusinterface.

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

from dsckeybusinterface.

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.

from dsckeybusinterface.

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.

from dsckeybusinterface.

Great to hear - as far as power, there are some notes in the develop branch README.md as well as discussion in issue #81.

from dsckeybusinterface.

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

from dsckeybusinterface.

Great, thanks for the contribution! Feedback from the populated PCB would be great.

from dsckeybusinterface.

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?

from dsckeybusinterface.

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.

from dsckeybusinterface.