-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Doesn't connect to AC3829/10 since version 0.1.3 #15
Comments
Oki, I think we need to debug that. Please:
Post the output here please |
Thank you Apollon77 for looking into this issue. I did as you described and got a very lengthy output which I attache as file. I waited until the adapter seems to reach a stable state (startup sequence finished), let it run for 2-3 iterations and than killed it with Ctrl-C. Hope that helps. If you need something else please let me know. 10.100.255.35 is the Philips air filter. |
Ok, was not that helpful as thought :-)) I did some adjustments ... please try again GitHub version and post debug log again (normal debug is sufficient) |
Hello everybody, same problem with the AC2729. With the old version, the AC2729 connected, from time to time the adapter needed a restart, because it lost the connection, but worked. Since the new version, the AC2729 doesn´t connect. :-( |
Then Install GitHub version and provide a debug log please |
Okay, installed the new version from GitHub and now the debug level in the normal log looks like this:
philips-air.debug-20220322.txt Hope that it is more helpful now - if not and you want me to run another trial version just let me know. |
Ok, also er macht mal mindestens einen Request zum gerät ... aber bekommt scheinbar keine Antwort. |
Naja, das sieht schon deutlich anders aus, auch wenn auch mit der Version die dritte grüne Haken bei dem Adapter nicht kommen will.
... und der Mitschnitt von der Konsole: |
Kann ich so bestätigen. Bei mir sieht das Log genauso aus. Der dritte Haken will nicht kommen, bei den Objekten -> Connection = false. Log-Größe: 11.1 MB
|
Ok, we need to dig trough it one step afetr the other ... please Guthub again ad provide debug log |
Re-Install the adapter from github. Here is the log:
Thank you so much for your support!!! |
So now it works??? |
Okay, nächste Runde:
... aber Zustand ist noch immer der Gleiche: der dritte grüne Haken kommt nicht! |
Sorry, nein, der Adapter funktioniert noch nicht. Dritter Haken fehlt weiterhin, Connection = false. (Das Danke bezog sich auf deine Unterstützung und deine Zeit. :-) Sorry für die Verwirrung.) |
Na ok :-))) Dann debuggen wir mal weiter im Code-Flow ... Next try please ... hab vllt was gesehen was komisch ist und gefixt ... lets see |
Freut mich, dass Du dran bleibst! :-) Normales Log:
... und Konsolen-Ausgabe: Aber der Zustand ist noch immer unverändert: kein dritter grüner Haken.... |
Slowly I miss ideas -... please try again (new GitHub version) |
Next iteration - normal log:
and captured console output: |
In fact the device does not respond ... question is mainly why ... Can you do me a favour and try e.g. https://github.com/rgerganov/py-air-control if that works in general (before we somehow hunt ghosts because reason is somewhere else?) I also do not want to break it for potential pother devcies where ich might work |
I installed it the way it described on the linked GitHup page:
and it works:
returns the status of my air filter:
So, we are not huting ghosts I guess.... ;-) |
By me the same. [name] Name: Schlafzimmer |
Ok, good to know that it is not caused by the device itself - just wanted to be sure :-) Please try again GitHub version ... I diwngraded the coap lib again to exact version as before |
Please open new issue for this topic with a debug log :-) |
Okay :-) Thank you again |
ould I please also see a debug log of a working version? :-) |
Sure ... but tomorrow - my computer is already asleep. ;-)
|
@boos87 maybe we can have two think together: Send a debug log that trggers your error line fromabove ... then I can see why |
Ok, Danke, sind also immer noch "nicht funktionierend". Gut wir suchen weiter |
Yes, unfortunately it doesn´t work. So i think, the new version in context with the debug leads to a crash of my Pi 4with 4GB. I have deactivate the instance from Philips and the Pi works without problems. |
@boos87 @chris-hoe Ok, hopefully last try ... @JKRhb was finally able to identify and hopefully fix the issue ... |
Hi, i have tried the version on github. Debug-Log:
No connection to the device... |
meehhhhh :-( Any one of you capable to run Wireshark to sniff network traffic? |
@Apollon77: yes, I can do that. What exactly do you want me to look at? |
Ideally:
|
@Apollon77: sorry, I had to leave for a business trip until end of this week. I can't do the test before next week. |
All fine ... I think we might have another test then |
Ok, here we go .... GitHub has another test version ... Please check when you find time |
Hi Apollon77, sorry, the new version doesn´t work. No connection.
|
GGRRMPPPFFFFFF%&%UIHGUZ%%&/%/&%&/(&$%(/&$(&/$(/&$(/&$$678 :-( Thank you ... |
@chris-hoe Any chance for Wireshark when you have time? |
Yes, I plan to do that on Monday.
…On May 14, 2022 12:14:25 AM Ingo Fischer ***@***.***> wrote:
@chris-hoe Any chance for Wireshark when you have time?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Hi @Apollon77, |
Thank @chris-hoe, I think that should help a lot with debugging :) I think the crucial lines are these: As it seems to me, the socket of the client seems to be closed too early, which leads to the discarding of the observe responses. |
Hmm, seems as if the server uses the wrong port in its responses, which causes the ICMP messages. I haven't been able to figure out why that is the case. The observe code itself does not seem to have any problems, I adapted it for the example below which works fine: const { EventEmitter } = require('events')
const coap = require('coap')
const eventEmitter = new EventEmitter()
eventEmitter.on('debug', (data) => console.log(data))
const address = 'californium.eclipseprojects.io'
// const address = '20.47.97.44' // Using an IP address also works
function subscribeOnStatus () {
return new Promise((resolve, reject) => {
eventEmitter.emit('debug', `GET /sys/dev/status to ${address}`)
const statusRequest = coap.request({
method: 'GET',
pathname: '/obs',
host: address,
protocol: 'coap:',
observe: true,
confirmable: false
})
statusRequest.on('response', res => {
res.on('error', err => {
console.error('Error by receiving: ' + err)
eventEmitter.emit('error', 'Error by receiving: ' + err)
res.close()
reject(err)
})
res.on('data', chunk => {
eventEmitter.emit('debug', `Subscription data incoming: ${JSON.stringify(chunk)}`)
resolve && resolve()
resolve = null
})
})
statusRequest.on('error', err => {
console.error('Error by sending: ' + err)
eventEmitter.emit('error', 'Error by sending: ' + err)
reject(err)
})
statusRequest.end()
})
}
subscribeOnStatus() |
Hmm. Had another look into the Wireshark logs. The successful and unsuccessful runs seem very similar. The key difference is that during the unsuccessful one, the server keeps sending observe responses to the same port, which is not active anymore. In the successful ones, the port changes to the new port after a renewed observe GET request. The POST request looks it is working, so an exchange seems possible in general. Any idea what could cause this behavior? Maybe the AC3829/10 needs to be restarted before the connection attempt? |
@JKRhb but how it can be the device if the only difference is the node-coap lib used?! is the client sending the same stuff in both cases? |
I had another look and there is actually one small difference between the two observe requests: In the requests that work, the observe value of zero (i.e. the start value) is encoded with an option length of zero, therefore the option value is actually omitted from the packet. In the requests that don't work, the option value of zero is encoded as one byte, where all bits are set to zero (see the screenshots below). So I guess the AC3829/10 cannot handle observe options where the zero is represented by ... zeros. Working request: Request that doesn't work: |
So, hopefully we are now at the end of the road .... Please try GitHub adapter version. Thank you |
Looks good - connects now. Wireshark capture attached - filtert this time, I figured how this works. ;-)
philips-air-0.1.6new_sucessful-connect-when-started.pcapng.zip |
Coooool. the warnings come from other packages in your whole npm tree ... can be ignored |
... but when installing the 0.1.4 version, those warnings are not shown. Maybe the 0.1.6 has additional dependencies? |
Interesting ... but effectively ... all good |
Thank you for your mega support on fiiguring thsi out ... v1.0.6 goes into Beta repo/npm today ... please check this officially again ... but I expect it to still work (fingers crossed) |
@Apollon77: Version 0.1.7 works with my AC2729/10. Great, thank you very much for your support!!! |
Since the latest update to 0.1.3, this adapter doesn't connect to my AC3829/10 anymore. With version 0.1.0 I had installed before, connection has always been a bit unstable and the adapter needed a restart from time to time but in general it worked okay.
Debug log isn't very useful to identify the problem (at least to me):
Looks like everything is working okay ... except that no values are coming in and the "Instances" tab is showing this adapter as "Not connected to device or service" (last checkmark is red instead of green).
Anything I can do to help fix this bug? I really would love to get my values recorded again! ;-)
The text was updated successfully, but these errors were encountered: