-
Notifications
You must be signed in to change notification settings - Fork 13
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
conversion_type = bool #126
Comments
What do you think of adding a ‘conversion function’ for fields? Then you could something like this.
|
Yes, that sounds promising. I would surround the call of that function by |
Good point about the try/except. I had to that for the simple calls to convert the values. But, I am thinking that I might have ‘catch’ more (all?) exceptions, because who knows what the lambda function might raise.... |
Doing some experimentation, I was able to get SyntaxError and NameError exceptions raised at ‘compile’ time. Since the expression is ‘compiled’ at initialization of WeeWX, if they are not handled it results in WeeWX not starting. So at this time, I see no reason to do anything more for these. |
@roe-dl |
Yes, that would be nice. |
Great. I have created this release. |
I added the following configuration to the end of the [[topic]] section:
I subscribed to the MQTT broker by MQTT Explorer. The topic "wetter/regnet" is there, and the sensor publishs to it once every minute. I switched on logging for MQTTSubscribeService and set logging_level to "DEBUG". Every record is logged to syslog. I see other topics received by MQTTSubscribe, but the topic above I do not see.
This is the only record where "isRaining" is logged between start and stop of WeeWX. All the loop records do not include it, but they include other topics received by MQTTSubscribe. I tried different values for "conversion_type" including "bool". Now I am not sure what to do next. |
Try grepping on the topic, wetter/regent. The early processing of MQTT messages includes the topic in the log. I believe there should also be some messages about subscribing to it. |
You are right:
|
By looking into the code I found that there is a log level "TRACE", too. I tried it, but to no other result. Additionally I changed the configuration a little bit. I commented out the line "conversion_type". No difference. I changed True to 1.0 and False to 0.0. No difference. Actually I see no further way to debug. |
The code snippet is implying that the subscription is never fully completed. If you grep on a different topic, you should see something like The TRACE level just logs the internal processing in even more detail. For this topic, we haven’t yet gotten the subscription to work. |
I thought TRACE is more than DEBUG and includes all the debug messages. But that seems not the case, if I consider your reply. So I repeated the test with setting DEBUG. Especially there is no "incoming" message, if I set TRACE, but there are such messages if I set DEBUG. For another topic I saw:
For our topic "wetter/regnet" I see:
The "subscribed" message never includes a topic but a value called "mid", that is also found within the "subscribing" message. So I guess the message with the same "mid" value belong together. I can't see a real difference between the two pairs of messages. But your comment led me into another direction. Indeed, there are "incoming" messages for the other topics, and for "wetter/regnet" they are not. So I looked at the access rights of the MQTT broker. While anonymous clients can subscribe to all topics, named clients cannot. And for the user name that the MQTTSubscribe service uses, I had not granted the right to read "wetter/regnet". After changing that, the value is received. Now every minute there is an "incoming" message for "wetter/regnet". And the value is processed within WeeWX. The value is converted as said by the conversion function. It is working as expected. 👍 :-) Thank you very much for all your work. And sorry for wasting your time. It is the old rule: the problem is situated between monitor and chair. |
No apology needed. Only seeing part of the picture can make it a challenge. Glad I could help. Yes, the ‘mid’ ties ‘subscribing’ and ‘subscribed’ log messages together. I believe it is short for ‘message id’. It is the information that MQTT client provides. I suppose I could do some mapping, but for debugging it doesn’t seem worth the effort. The ‘difference’ is subtle, if at all. The ‘subscribing’ message is just logging that a ‘subscription request’ has been ‘submitted’. The ‘subscribed’ means that the subscription was ‘accepted/completed’. I know the wording could be improved, any suggestions are welcome. (I am also working on a wiki page...) Your understanding of how TRACE level debugging should work is correct. Seems like a bug. I’ve opened #128 to track. Once I get the logging on exceptions improved, I should be able to package this up into a formal release. Thanks for your help. |
So I guess, this issue can be considered solved and can be closed. Thank you again. |
* default back to system python3 * basic functionality for #126 * 'catch' additional exceptions * just 'catch' ValueError - Although I have seen NameError and TypeErrors, these have been due to expression 'errors' - Whereas the ValueErrorbis due to the input. - Can adjust after real world feedback. * checkpoint - store conversion_func differently * cleanup the storing og conversion_func * cleanup exception logging
The data source delivers a boolean value as 'ON' and 'OFF'. Unfortunately, the standard conversion function in weeutil.py only knows 'True'/'False' and 'Yes'/'No' as string values.
Would it be possible to have 'ON'/'OFF' as additional possibility for a boolean value?
The text was updated successfully, but these errors were encountered: