Hi Peter,
very glad that you want to start again with the binding.
I own a Stiebel Eltron WPF 10 E with a DCo Aktiv adapted (which should be in the end something like a CAN -> Serial Adapter).
I have a little experience with binding development (unofficial hoermann bisecure Binding), so perhaps I can support you there too 
Regards,
Thomas
ok, sounds we have enough user here.
in the meantime i already setup my IDE of openhab and will try to all code on the latest status.
i saw some discussions from t200 to resolve the issue i reported integrated that into my version.
cross fingers that the stuff is working
hi guy,
final have a new version, thanks to t2000 who solve the issue with the resolver.
2.5.4-snapshot
i guess you know how to deploy that version into you system.
have fun
hi thomas,
concerning the CAN -> serial adapter.
i guess that CAN would need a new implementation of the protocol part.
Do you have more inside you can share how the CAN is made available and some document on the CAN implementation in the heatbump?
Hi Peter,
unfortunately I have no further documentation. The DCo Aktiv was the adapter which came together with the ComfortSoft software to control the heatpump remotely. Which worked ok on my old Windows XP machine (even with tunneling over ethernet with net2serial).
I think there are already open source protocol implementations around, I will google that…
Regards,
Thomas
hi all,
i am currently testing the new binding.
here are some teaser from first day
first shot shows the paperUI with some live data from heatpump
maybe you could share your monitoring views.
Not decided yet on which UI in openhab to take
cheers
Hallo Peter,
I am glad to hear you want to continue with that binding! Your stats look promising. I have similar ones as well, thanks to you great work on the binding! What I noticed is that the fan speeds are definitely wrong, but that also applies to my heatpump, so nothing serious, but should be fixed by us at some point.
I think you have found my https://github.com/t2000/openhab2-addons/tree/tecalorBindingWIP branch, right?
I called it WIP because the only stuff I did so far is to make it compile again in the new bnd workspace and I refactored the class names a little to be conform to Java and openHAB standards.
Also I hacked into the binding a thing type for my heatpump a Tecalor 5.5 which has integrated ventilation. Thus as a quick hack I only added test channels to control the ventilation stage for day and night. I basically took the commands from the FHEM integration and hardcoded the values 
Regarding the Typeresolver that you were using: I think there is unfortunately a general misunderstanding when it comes to Channelgroups and how they are used by you in the binding. As far as I remember I replaced it with the ChannelTypeRegistry to get the binding working again.
However, this is NOT a solution for a binding that will eventually be integrated into the official openHAB code. The reason is that a binding should NEVER need to query any registries (be it ThingTyperegistry, ThingRegistry, ChannelTypeRegistry, ItemRegistry, or whatever). It should not even know that these exist.
When I said there is a “general misunderstanding” regarding the ChannelGroups I mean this: ChannelGroups in openHAB are designed to group some channels together is order to re-use them in different ThingType definitions. Their existence is just for this one purpose, nothing more. it should take the effort from a binding developer to duplicate channel definitions on each thingtype where the channels occur.
At runtime, i.e. when the openHAB system is running, the Thing object has Channels ONLY. The groups are GONE and there is no way to obtain the information if a Channel was part of a group or not. Basically what happens is that all Channels are glued flat to the Thing. And this is the reason why the concept on how the ThingTypes are defined currently has to be optimized.
I was busy in the past days to finish my binding for the Nova fine dust sensor (https://github.com/openhab/openhab-addons/pull/7528) and once this is running fine in my docker container alongside the heatpump which also creates a ttyUSB device, I can continue to contribute to the stiebelheatpump binding. I really would like to see it as part of the official openHAB distribution.
So I guess the next steps are to think about a concept of getting rid of the “channelgroup misuse” and then take it from there.
If you like we can also have a (voice) chat sometime to discuss things, maybe also in german as I see you are from Germany too. Just let me know if a discussion/brainstorming would be of any help and we can arrange soemthing.
Regards,
Stefan
PS: The “t2000” is actually my private account, whereas “triller-telekom” is my business one, just to solve the confusion why I post with 2 nicknames
I guess it is better to stay in english in the forum even if we both speak german.
First of all many thanks for resolving the issue with the channelgoups.
I was replacing my server infrastructure during Christmas and now with corona virus got a bit more time to start again some work on the binding.
Some background on the decision to used the channelgoups in the thing-type definition. I the 1.x version of the binding i choose an external xml configuration to define the registers with its settings, states and counters to define per heatpump version the required information.
Then came OH2 with PaperUI and channel concepts and the thing-type definition. For my was appealing to use the thing-type to include this configuration as channelgoups fits to the registers . That’s why .
Would be very good if you could share some ideas what are the best patterns to do it the right way. Let me know which direction i should go.
Concerning the code status, i just setup the IDE to find out if it work. id did not created yet any branch in git to allow making a PR and as you said with the current concept it most like does not get accepted.
I yesterday move the serial implementation to the org.eclipse.smarthome.io.transport.serial as i had issue with a USB converter.
So i would be able to continue working on the binding getting feedback from users in that discussion.
In the meantime i would setup git in a way to get it prepared for PR.
BR
peter
Great work.
This binding works for me.
Last time this binding works was on OH2.2
Thank you!
hi mike
very good. Could you share the version you use and the interface connected.
thx
peter
LWZ 304 Firmware 7.39
after a restart from OH i have this error
[ERROR] [atpump.internal.CommunicationService] - heat pump communication could not be established ! no data availabel!
[ERROR] [atpump.internal.CommunicationService] - Error reading data : org.openhab.binding.stiebelheatpump.internal.StiebelHeatPumpException
[INFO ] [pump.internal.StiebelHeatPumpHandler] - Heat pump has version null
[ERROR] [pump.internal.StiebelHeatPumpHandler] - Thingtype version of heatpump 7.39 is not the same as the heatpump version null
[hingStatusInfoChangedEvent] - 'stiebelheatpump:stiebelHeatPumpLWZ303_7_39:dee5ce93' changed from INITIALIZING to OFFLINE (CONFIGURATION_ERROR): Error occurred while initializing stiebel heat pump handler!
hi mike,
sieht so aus das die communiation nicht mehr läuft.
ich habe gestern noch implementation der seriellen Kommunikation auf die interne OH2 umgestellt.
Was hast du genau für eine schnittstelle in deinem Rechner?
hier mal die version die ich im Moment bei mir laufen habe
binding
Hi Peter
My Raspberry 3 is direct connencted over USB to the LWZ.
My LWZ has one USB port in the front.
Until the restart, the connection was fine.
With the last binding the mproblem is the same.
strange that it worked before the restart
hi mike,
go to the karaf console and enable the DEBUG log on the bundle.
ssh -p 8101 openhab@localhost
log:set DEBUG org.openhab.binding.stiebelheatpump
log:tail
then we should get more insides
BR
Peter
16:48:44.793 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Initializing stiebel heat pump handler 'stiebelheatpump:stiebelHeatPumpLWZ303_7_39:dee5ce93' with configuration: port '/dev/ttyUSB0', baudRate 19200, refresh 60.0.
16:48:44.878 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : Name -> version, Description -> Version information of heat pump firmware , RequestByte -> FD
16:48:44.886 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - set version request : Version information of heat pump firmware
16:48:44.894 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : Name -> time, Description -> Date and time information of heat pump , RequestByte -> FC
16:48:44.903 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - set time request : Date and time information of heat pump
16:48:44.908 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : Name -> currentValues, Description -> Temperature measurements of the heat pump. , RequestByte -> FB
16:48:44.916 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : Name -> operationCounters, Description -> Reads Operation counters of the heat pump. , RequestByte -> 09
16:48:44.925 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Request : Name -> nominalValues, Description -> Reads settings nominal values of the heat pump. , RequestByte -> 17
16:48:44.964 [DEBUG] [eatpump.internal.CommunicationService] - Loading version info ...
16:48:44.969 [DEBUG] [eatpump.internal.CommunicationService] - Request : Name -> version, Description -> Version information of heat pump firmware , RequestByte -> FD
16:48:44.977 [DEBUG] [eatpump.internal.CommunicationService] - Sending start communication
16:48:45.999 [ERROR] [eatpump.internal.CommunicationService] - heat pump communication could not be established ! no data availabel!
16:48:46.005 [ERROR] [eatpump.internal.CommunicationService] - Error reading data : org.openhab.binding.stiebelheatpump.internal.StiebelHeatPumpException
16:48:46.010 [DEBUG] [ebelheatpump.protocol.SerialConnector] - Interrupt serial connection
16:48:46.016 [DEBUG] [ebelheatpump.protocol.SerialConnector] - Close serial stream
16:48:47.059 [DEBUG] [ebelheatpump.protocol.SerialConnector] - Disconnected
16:48:47.069 [INFO ] [tpump.internal.StiebelHeatPumpHandler] - Heat pump has version null
16:48:47.080 [ERROR] [tpump.internal.StiebelHeatPumpHandler] - Thingtype version of heatpump 7.39 is not the same as the heatpump version null
16:48:47.103 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition collectorTemperatur in request currentValues:Temperature measurements of the heat pump.
16:48:47.106 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition flowTemperatur in request currentValues:Temperature measurements of the heat pump.
16:48:47.120 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request dHWTemperatur:{}
16:48:47.116 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition hotGasTemperatur in request currentValues:Temperature measurements of the heat pump.
16:48:47.109 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition returnTemperatur in request currentValues:Temperature measurements of the heat pump.
16:48:47.106 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition outsideTemperatur in request currentValues:Temperature measurements of the heat pump.
16:48:47.135 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request condenserTemperature:{}
16:48:47.130 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request insideTemperatur:{}
16:48:47.121 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request flowHC2Temperatur:{}
16:48:47.145 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request exhaustFanSpeed:{}
16:48:47.139 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request evaporatorTemperatur:{}
16:48:47.139 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request supplyFanSpeed:{}
16:48:47.137 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request extractFanSpeed:{}
16:48:47.157 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request heatingCircuitPumpStatus:{}
16:48:47.159 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request solarPumpStatus:{}
16:48:47.153 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request dHWPumpStatus:{}
16:48:47.148 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request filteredOutsideTemperatur:{}
16:48:47.146 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'stiebelheatpump:stiebelHeatPumpLWZ303_7_39:dee5ce93' changed from INITIALIZING to OFFLINE (CONFIGURATION_ERROR): Error occurred while initializing stiebel heat pump handler!
16:48:47.175 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request CompressorStatus:{}
16:48:47.174 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request DiverterValve:{}
16:48:47.169 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request heatPipeValve:{}
16:48:47.167 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request mixerClose:{}
16:48:47.163 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request mixerOpen:{}
16:48:47.190 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition compressorA in request operationCounters:Reads Operation counters of the heat pump.
16:48:47.187 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request BoosterStage2:{}
16:48:47.187 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request BoosterStage1:{}
16:48:47.181 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition currentValues in request BoosterStage3:{}
16:48:47.206 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition operationCounters in request coolingMode:{}
16:48:47.205 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition operationCounters in request dHWMode:{}
16:48:47.200 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition operationCounters in request heatingMode:{}
16:48:47.194 [DEBUG] [tpump.internal.StiebelHeatPumpHandler] - Found valid record definition compressorB in request operationCounters:Reads Operation counters of the heat pump.
I will check the connection to the LWZ again
The connection is OK.
Is there another way to test the connection?
the issue is that the initial communication to verify the version is not working.
it is strange that it was working initially and then stopped.
also i changed the code to verify if the serial port is available in the beginning. It looks like the port is available to java.
could you share
lsusb
setserial -g /dev/ttyUSB0
ls -l /dev/tty*
setserial -g /dev/ttyUSB0
“cannot get serial info inappropriate ioctl for device”
does sudo setserial -g /dev/ttyUSB0 work?
No, unfortunately not, the same mistake