[boschshc] Add support for Relay - 'MICROMODULE_RELAY' #16590
Comments
mike-bike
added
the
enhancement
|
Thanks for the enhancement request. Assuming you can help with testing again we can start coding as soon as someone finds some spare time 👍 |
|
Absolutely! Just let me know when you have something ready to test. My PI2 test bed is always yours :-)
Happy Easter!
Kind regards
Michael
… Am 31.03.2024 um 15:12 schrieb David Pace ***@***.***>:
Thanks for the enhancement request. Assuming you can help with testing again we can start coding as soon as someone finds some spare time 👍
—
Reply to this email directly, view it on GitHub <#16590 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHVH7GBTL7ATBMQU3WAVTP3Y3ADTNAVCNFSM6AAAAABFM3A4SKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRYG4YTSNRZGU>.
You are receiving this because you authored the thread.
|
|
Hi @mike-bike, apparently the relay can have different configurations. I see the following
From what I've learned in tschamm/boschshc-hass#101, one of these modes (the "light" mode) features a "toggle" button and the impulse switch mode only has a "push" button. Can you please check/answer the following:
|
|
I'd need to check the logs to confirm the services/responses when the configuration changes. Maybe I find some time later today or tomorrow. I am trying to answer your other questions:
I will amend my findings after reviewing the logs |
|
Hi @david-pace, after reviewing my previous post, I do not think you need to worry much about the relay's device configuration. I think these parameters only drives the BOSCH bridge/app internal functionality:
From thing's perspective I'd see it as just an on/off switch. The Though it would be nice to expose the Still wondering about Unfortunately I cannot complete the testing because I do not have a Room Thermostat available to configure Electrical / Boiler modes. Again, I don't think it will differ based on my findings above. |
|
I have tried different configuration, but the result seem to be always the same. We probably need to have a thing configured to get more details if needed: |
|
Thank you for the information, @mike-bike 👍 In this case I would propose to implement a minimal set of services and then provide a test JAR. Then you can test with the hardware how the individual services react in which mode. |
|
Sounds like a plan 😀 Regards Michael
|
|
Hi @mike-bike, good news, I have a first implementation ready that you can test 😎 Here is the link to the Test JAR. I think you already know the testing procedure, but if you have any doubts or questions please let me know 👍 I'm excited to hear what already works and what does not work 😉 |
|
Hi @david-pace, refreshed the test-bed and loaded the new JAR. I think, I experienced similar issues as with the first test of the Light Switch II. I recall, that you quickly have identified the root cause and provided a fix. So I am expecting nothing serious. Good progress! Quick summary:
PowerSwitch: Childprotection: PowerSwitch Program: ImpulsSwitch is not working After unlinking and removing ImpulseSwitch Item, Thing turned immediately into GREEN Error in Thing: |
|
Thanks for the initial test 👍 Could you please look in your logs for example requests/responses for the relevant services? You can identify them by the following
I need to know the exact spelling and a few examples of complete requests and/or responses if possible. |
|
Not sure if that is what you are looking for. I found the binding to be reverted to the supplied one. I have stopped openHAB, clean-cache, and restarted. Then upgraded the binding again. Interestingly, during a short period Switch, Child Protection, and PowerSwitchProgram were working in both directions. Then suddenly, it stopped... Very strange - changes in Bosch App get not reflected in openHAB. There are also no traces in the log on changes in the App. Switching off/on in Bosch App Switching Manual/Automatic in Bosch App Childprotection in Bosch App |
|
Thanks for looking into the log files 👍 First, a few general explanations:
So far I have identified 2 issues:
I will provide a new JAR with fixes for these issues as soon as I find some time. And I have two questions:
|
|
You are right. All Updates from Bosch are broken. Will check this afternoon Gruß Michael
|
|
I do not think I'd assume
Yes, this is correct understanding. On/Off Switch item is working, but does not show changes from Bosch app.
Last Long Poll response was I am going to stay away from these dangerous items... A |
|
I just uploaded a new JAR with a few enhancements and fixes (under the same link). Please delete your channels and the relay thing before you download the new JAR. Changes:
I have a theory about the impulse switch service, maybe you can help me verify whether it's correct: In my opinion we need the impulse switch channel and service, because I don't think Bosch would advertise a service that is completely useless. This is also indicated in tschamm/boschshc-hass#101. So my theory is that the relay can be operated with the I'm excited to learn whether if it works better with the new version and if I was able to mitigate the long poll issues. |
|
Ok, now I slowly understand. I was confused because the relay need to be configured differently during the initial training in the Bosch app. My bad - I did not realized that. During first initialization in the Bosch App, you need to define the "mode" of the relay:
You cannot switch between both modes in the Bosch app. I had to remove the device and reconfigure. Now the app does no longer provide On/Off toggles but only a pushbutton. When I press it, the relay close for the 1 sec (configured time between 0.5 and 20secs) and then opens again. I tested the binding with the relay in Then I deleted the device from the app and re-connected it selecting "Impulse Mode" during setup. I have unlinked the items and deleted the thing. Triggered rediscovery, added thing and relinked items: that messed up the long-poll and I could not get anything working with the items (Child-Protection was working at the beginning). Need to re-do in a more structured approach.
In that configuration there is no and on but the relay does not switch at all. When I press the push button in the app the following is visible in the log: and after the defined duration (here 10 seconds - the config seems to use 0.1th seconds i.e. 100) the relay turns off: It seems that the push-button requires a more complex command to fire... Getting it to work will still leave the same questions as discussed in the HA article. May I propose the following: PowerSwitch configuration ImpulseSwitch configuration: Regards, |
|
Thank you for this analysis 👍 So my theory that only one of the services is available/used was correct. But the impulse switch is more complex than I thought. I will think about how we can configure the channels automatically based on the configured mode/profile. Could you please help me determine all the possible identifiers for the Thanks to your log output I can now properly send and receive messages for the |
|
Hi @david-pace, I am happy to help. I'd consider the two modes I think you have summarized the variations correctly in your post above PowerSwitch Mode: Please note, that the PlugCompact (Zwischenstecker Kompakt) also supports the same three profiles, but with only three options in the app: choices: From openHAB perspective all 4 profiles should work the same: an On/Off switch turns the relay on and off. I do not know how the heating modes will be displayed. It could be, that they are linked to a Climate Control. I will ask around if I could borrow a room-thermostat. ImpulsSwitch Mode: |
|
Thank you for the detailed update ❤️ I think we should go for the property-based approach. I was trying to figure out a criteria to detect whether the relay is configured as regular power switch or impulse switch. My idea was to check the profile value, but now I understood that my idea does not work. I thought we always have the same list of available profiles, but these also change depending on the configuration. My new approach would be to check the list of device services. If |
|
Hi David, looking for the device services shall be the right method. Pending on the configuration it should either offer |
|
Hi David, not sure if it is really related, but I feel that calling inappropriate service kills the long-poll process. I just found the updates from Bosch binding missing since yesterday 23:13. I had the thing configured as ImpulseSwitch and in the late evening changed the configuration of the relay back to PowerSwitch. I have missed to unlink the items and re-creation f the thing... It seems that the code is sensitive to the long poll responses and cannot recover from an error or unexpected result. |
|
Hi @mike-bike, I uploaded a new version of the JAR. Please unlink the channels and delete the thing before updating it. Changes:
Excited to hear whether it works better now 😎 |
|
Hi @david-pace, I have downloaded new JAR, unlinked all items and deleted the thing. Then updated binding with new JAR. PowerSwitch Mode:
Then unlink items and deleted thing in openHAB and device in Bosch app. Reconfigured relais in ImpulseSwitch Mode:
Overall, great progress. I am going to test setting Regards, |
|
Hi @david-pace, I tried to test with
The way In summary:
Many thanks for the great work. In summary it would be working for me. However, invalid channels could confuse the user. Please advise, how I should update the I will be on vacation starting on Monday and returning on May-1st. Please expect my delayed response on further testing. Regards, |
|
Thanks for the detailed tests ❤️ When you are back from your vacation, you can test the new JAR I uploaded. Fixes:
TODOs not yet fixed / to be discussed:
|
|
Hi @jlaur and @lsiepel, we have a technical question: we have a relay device that can be one of two modes: Power switch mode ( Depending on the mode, the device exposes different services. In Particular, in power switch mode there is a I managed to deactivate the corresponding channels based on the thing property internally. So if commands are sent to inactive services, the implementation simply ignores these commands (not ignoring them would lead to errors when sent to the controller). But @mike-bike, who was so kind to test my code with real hardware, mentioned that from the user's perspective it would be even better if the irrelevant channels were not even visible in the UI. So the question is: do you know if there is a way to completely hide certain channels from the UI depending on a thing property? Thanks in advance for your support 👍 |
|
Hi @mike-bike, yes please do test everything again. I think the pull request was closed too soon. If there are any issues I will address them in additional pull requests. |
|
Status: relay configured in impulse mode
Part 2: reconfigure relay as on/off switch
Any thoughts? I will restart OpenHAB and check if this changes anything later... |
|
Stopped OpenHAB and cleared cache. I have missed to check explicitly other Bosch things, but I assume that long poll stopped working until reloading. At least I have not recognized any updates in the log. I cannot assess the effort required to fix the thing, but I now feel unsure about the chosen design and would like to propose an alternative approach: The relay device requires deletion and adding a new device in the Bosch App. With that, it could be considered as a different device with unique characteristics serving a different purpose. What if the current configuration ( |
|
I agree that we should at least try this alternative approach. It seems like the effort getting the dynamic channel creation to work is not worth what we get in terms of user experience - we already discussed that changing the device configuration happens rarely (i.e. when the device is re-purposed), and then it is acceptable to re-create the thing. Even with the dynamic channel creation working the user would still have to do some manual steps, in this case triggering a re-initialization somehow. I will implement the simplified approach, and even add another simplification: we don't need to store the current configuration in a thing property. I think we already discussed that this would not work in certain scenarios. Also the channel configuration already tells us in which mode the thing currently is, so we don't need to store it explicitly. I will provide a JAR soon, stay tuned 😎 |
|
Hi @david-pace, after thinking about the proposal I am even in more favor of it. Assuming the dynamic channel creation works, the user needs to action anyhow as orphaned items could be used in rules, triggers, graphs etc. Not sure what you mean by "storing the configuration as a property". My proposal was to store the instantiated mode as a fixed string in a property. Like "Location" in sample image below; e.g. I do see the benefit in being fully transparent to the user. In case the thing identifies a configuration change (i.e. different to what was instantiated) it should switch into Anyway, I am looking forward to testing the new JAR. :-) 
|
|
Hi @mike-bike, maybe my wording was ambiguous. With current configuration I indeed meant the current mode ( If you remember I already implemented this in a previous version, but @jlaur mentioned that this does not work, at least not if the property is set during discovery (see #16590 (comment)). I have to think about it whether it would work if the property is set during the first initialization. @jlaur do you have any input on that? |
|
Now that you mention it... I vaguely recall. I think I already had proposed a similar solution ( #16590 (comment)) |
If a property can be set on first initialization, what prevents it from being determined on each initialization? |
|
I just uploaded a new JAR implementing the new approach 👍 EDIT: @mike-bike you asked about how to set the impulse length. The unit of the duration is deciseconds, i.e. tenth seconds. For instance, to set a delay of 1.5 seconds you would set |
|
Testing it. Deleted old thing and updated bundle... Relay device configured as Power Switch - recognized correctly - Property set ok: Testing functionality
Now reconfiguring device into Impulse Mode
7. Disabling the Bridge and re-enabling it again, generates the same
==> It seems that configuration change is identified correctly, but Error condition does not prevent initialization (fall-through IF-condition?) Manually deleted thing and manually added again (re-scan correctly identifies Impulse Switch)
Summary Cheers |
|
Thanks for testing ❤️ We're nearly there 👍 I just uploaded a new JAR that should fix the ERROR / ONLINE switching issue. Can you please test again? Regarding the impulse length issue: did you read my EDIT here explaining that the impulse length is set in tenth seconds? Also, I added logging in Question to @jlaur and @lsiepel regarding the properties: please refer to the screenshots @mike-bike provided in #16590 (comment). We have an existing property Same question for the property values. I now just used the Bosch service identifiers (which are |
There is no convention for values, but generally they start with capital letters when it makes sense to do so (for example |
|
Hi @david-pace, I do not have much time for extensive testing. However, I have checked functionality with last Impulse configuration working fine. Then reconfigured device into PowerSwitch mode and received error state as expected: The changed device config into Impulse again and stopped/started Thing. It went to online immediately and channels picked up current values (e.g. had changed Impulse length during config in Bosch App). Functionality looks good. You may want to adjust the strings according to the advice given by the others. I am personally fine with the code... All seems to be working fine. However, I do not see changes in OpenHAB to Impulse Length coming through. I have created dummy Blocky script to change duration: Item value got updated, no info in log (even on Trace) and Bosch App shows old value. 
PS: What state of the Bosch binding is delivered with the 4.2.x release? I do see connection loss to Bosch (long poll stops) after few hours again. Have now loaded current 4.3 Bosch binding and it seems to be stable again. I thought the connection issues had been fixed long ago and that code should have been merged... |
|
Great that the thing status update now works properly 👍 According to the useful advice provided by @jlaur I will keep the property name lower case as specified in the coding guideline. The location property name will be changed in #16599. Regarding the impulse length update: it looks like you're sending a string command, but the channel only accepts numbers. Maybe it works when you send an integer number to the item? @jlaur what is the best practice here? Should the numeric channel also accept string commands, and then try to parse the string as a number? |
|
@david-pace, I think commands only works on strings anyway. The state of the item itself is changed correctly but I cannot see any evidence in the log, that the change is sent to the device. I will do some further testing tonight. |
I don't think so, or at least I think that should work automatically. Do you have an example? I tried this without any issues: openhab> openhab:send Signe_Gradient_Floor_Color 50
Command has been sent successfully.
openhab> openhab:send Signe_Gradient_Floor_Color "10"
Command has been sent successfully.
openhab> openhab:send Signe_Gradient_Floor_Color "0"
Command has been sent successfully.I believe the reason it works is that in all three cases the binding receives as |
|
I have tried the same from Karaf as @jlaur. It does not make any difference: Item status is immediately updated in openHAB showing Please note, that I do see same when I trigger the button in the Bosch App... When I change the impulse length (here to |
Oh, it's |
|
Ah ok, not a |
|
This seems to be the issue. I have added another item without any dimension and changes to that are shown in the log and also reflected in the Bosch App Though the handling in the channel needs to be adjusted, as the channel itself suggest a quantity type Interestingly using the quantity type does not show any error in the log. The command is silently ignored. Thanks @jlaur for the hint! |
|
Btw: Sending other values, than selectable in Bosch App seems to be accepted; e.g. 23 is shown as 2.3 Sec in Bosch App. Even 500 or 5000 seems to be accepted. Very short durations of 1 (0.1s) and 2 (0.2s) also working. |
|
ok, the JAR is updated 👍 Thanks for the hint with the The channel now accepts both |
|
Looking good! I have tested with Thumbs up! Do you want me to do full regression? |
|
Cool 😎 Now we should have everything covered. I will open the pull request for code reviews. Normally everything else should still work because I have unit tests in place, but of course it's always better to have a confirmation by testing all channels with the real hardware again, if you find time for it. Thank you for your continuing and valuable testing support ❤️ |
This request is to add support for another Bosch Smart Home device, namely Relay:
From openhab.log:
Unknown deviceModel 'MICROMODULE_RELAY'! Please create a support request issue for this unknown device model.Please let me know if I'd need to provide further details or can support testing.
Happy Easter!
Regards,
Michael
The text was updated successfully, but these errors were encountered: